Support ACCEPT_EULA as '1' or 'true'

[jirisykora83]

Hello could be possible to add support for 'ACCEPT_EULA' other values then 'Y'. I use seq on my local machine with swarmpit (and they by default strip ' around 'Y' and then I have to manually add every time when edit my docker-compose (via their web UI).

[nblumhardt]

Hi Jiří, thanks for getting in touch!

This one sounds like a swarmpit editor bug;'Y' and Y reflect different intentions in YAML. Raising a ticket there would likely benefit everyone else using the editor, so that might be the best place to start?

We'd give this some consideration but it's not a change we'll be able to make in the very short term. It's great to know about, though, I can see how there's a bit of a trap here :+1:

[jirisykora83]

@nblumhardt Thanks for response I would try but swarmpit repo seems to not deliver new versions over year, so that is the reason why I choose rise issue here and of course I know this is low priority but I will be happy if you consider this in some future update :)

Thanks for fast response 👍

[rpendleton]

For what it's worth, my docker compose file for Seq had been using ACCEPT_EULA: Y for the past year or so without any issues, but just today, I noticed my Seq container stopped running a few weeks ago. When I tried to start it manually, it showed the error message stating that I needed to accept the EULA by setting ACCEPT_EULA to Y.

I'm not 100% positive what changed, but if I had to guess, I think I happened to update from the older standalone version of docker-compose to the latest docker-compose-plugin around that time. Perhaps the parsing of Y changed between those two versions?

Troubleshooting this was a bit confusing, because the logs just said to set that environment variable (which seemed to be set), and I didn't realize there was a difference between Y and 'Y' in YAML. Also, several search results for "docker compose seq accept_eula" show compose files that don't use quotes (including the official readme for seq-input-gelf), so that certainly didn't help matters.

I'm sure I'm not the only person that has encountered (or will encounter) this issue, so I agree that it would be nice for Seq to support more than just the literal string 'Y'. Perhaps it can save others from losing ~2 months of logs like I did.

[nblumhardt]

Thanks for the note @rpendleton 👍

We'll include this change in 2023.1.

[liammclennan]

This issue seems to be caused by a change in the YAML specification. In older YAML specs, ACCEPT_EULA: Y was interpreted as ACCEPT_EULA: true (which Seq rejects). Recent YAML specs interpret it as ACCEPT_EULA: "Y" (which does work).

As a workaround to @jirisykora83's specific problem it is possible to use the 'array' syntax without quotes:

environment:
      - ACCEPT_EULA=Y

[jirisykora83]

thanks this seems to works.

[liammclennan]

We've decided not to make this change at this time because there is a workaround and because it is specific to an old version of the YAML spec.

I will update the seq-input-gelf documentation to use the correct syntax.

[rpendleton]

Although the YAML 1.2 spec says that only true and false should be parsed as booleans now, the latest version of docker compose (2.14.0 as of a week ago) doesn't actually use the 1.2 spec and still parses y as a boolean (despite the fact that YAML 1.2 came out more than a decade ago).

Even though I'd understand not caring about the old YAML spec, given that it's still in use by the latest docker compose, it seems odd to me that it wouldn't be worth making a simple change to accept additional values such as true and 1. I can't imagine that would take all that much time to implement, but it could save some users a significant amount of time by not requiring them to troubleshoot this in the future.

$ cat docker-compose.yml
version: '3.8'

services:
  ubuntu:
    image: ubuntu
    environment:
      myenv: Y

$ docker compose run ubuntu env | grep myenv
myenv=true

$ docker compose version
Docker Compose version 2.14.0

[nblumhardt]

Licensing-related things can unfortunately require a bit more care/time/effort; for example, ACCEPT_EULA: true would probably be a reasonable indication of license acceptance, but ACCEPT_EULA: On is more questionable - and the two would be indistinguishable. We'd need to dig in a lot more before making the change.

It's not impossible that we'll revisit this down the track, though. Thanks for raising/pushing on it, in spite of our conclusions we can see the friction here 👍