Add CI compose version 1.29.2 / 2.2.3

[aminvakil]

If it's causing issues (#1133 (comment)) why should we stick to it?

Also while we're here let's bump docker-compose 1.x version to latest release.

So this PR got changed in the way and at last min/max 1.x and 2.x versions of docker-compose added to CI as suggested by @chadwhitacre in #1251 (comment)

Also because of recent changes in 2.2.3 (docker/compose#9035) -T had to be added to some scripts using $dcr where output of it was getting used.

  -T, --no-TTY                Disable pseudo-noTty allocation. By default docker compose run allocates a TTY

[chadwhitacre]

Revert? 👀

[aminvakil]

Revert? eyes

Trying to see if the problem happens again with v2.0.1 or what? Sorry for the noise.

[chadwhitacre]

Ah, gotcha. I figured it was #1171. :-/

[aminvakil]

I'm running self-hosted (21.11.0) with docker compose v2.2.3 and I don't have a problem...

[aminvakil]

OK, So I went and checked this PR a couple of times during the past few days and couldn't figure out what is wrong with 2.2.3, last solution I have is to check every release between 2.0.1 and 2.2.3 to see what breaks where :) and then figure out why

CI Passed:

• 2.0.1
• 2.1.0 (not tested)
• 2.1.1
• 2.2.1
• 2.2.2
• 2.2.3

So the regression starts with 2.2.3 (https://github.com/docker/compose/releases/tag/v2.2.3) itself.

[aminvakil]

sentry-self-hosted-relay-1                                      "/bin/bash /docker-e…"   relay                                      restarting          

relay stucks in a loop:

2022-01-18T13:22:01.7151325Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7152059Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0
2022-01-18T13:22:01.7152692Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7153321Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0
2022-01-18T13:22:01.7153963Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7154568Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0
2022-01-18T13:22:01.7155214Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7155841Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0
2022-01-18T13:22:01.7156460Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7157079Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0
2022-01-18T13:22:01.7157698Z sentry-self-hosted-relay-1                                     | error: could not parse json config file (file /work/.relay/credentials.json)
2022-01-18T13:22:01.7158316Z sentry-self-hosted-relay-1                                     |   caused by: EOF while parsing a value at line 1 column 0

[BYK]

@aminvakil could this be some sort of Unix/Windows line ending issue?

[BYK]

@aminvakil, actually, I bet docker compose 2.2.3 is outputting some random/garbage values in the run output at this step:

self-hosted/install/relay-credentials.sh

Lines 16 to 20 in 13d14e8

	$dcr \
	--no-deps \
	--volume "$(pwd)/$RELAY_CONFIG_YML:/tmp/config.yml" \
	relay --config /tmp credentials generate --stdout \
	> "$RELAY_CREDENTIALS_JSON"

Producing an invalid YAML, causing relay to fail. That means getsentry/relay#1169 is invalid and we should address the issue here or with docker compose itself directly.

[untitaker]

@BYK are there any issues with not using --stdout and generating the credentials in a mounted volume?

I think the bug described in the comment above might also purely exist because you're redirecting stdout to a file instead of letting Relay create the file, because that creates an empty file before the relay process starts.

[BYK]

@untitaker using a volume is fine here but Relay does not like that scenario: getsentry/relay#564

[aminvakil]

I removed putting output to file to see what is the output in 6366592.
It seems that nothing gets generated at all using 2.2.3
https://github.com/getsentry/self-hosted/runs/4865126485?check_suite_focus=true#step:4:498
Same job with 1.29.2 though:
https://github.com/getsentry/self-hosted/runs/4865126429?check_suite_focus=true#step:4:717

I guess it's related to docker/compose#9035 which fixed another bug reported by @chadwhitacre :)

[untitaker]

using a volume is fine here but Relay does not like that scenario

That linked PR only changes relay's behavior when using the --stdout flag, but to be clear i propose not using that flag, not using > and letting relay create the credentials file itself, not the shell

[aminvakil]

Closing and reopening to see if kafka thing is temporary or not.

[BYK]

@aminvakil let's try what @untitaker suggest and remove the --stdout flag?

[chadwhitacre]

Oh wow I've been missing the party. 🍿

[aminvakil]

@BYK @chadwhitacre Sorry for answering late. I wanted to give myself more time to think about this.

@aminvakil let's try what @untitaker suggest and remove the --stdout flag?

I propose keeping this PR as it is, but create another PR which changes relay credentials generation as @untitaker suggests, and take a look at this PR after that has been changed, what do you think?

what do you think of testing against more than two versions of Docker Compose? How about min/max of v1 and min/max of v2? So ...

Sure, why not? I say add them later after merging the relay credential PR.

[BYK]

If -T fixes things, I actually like this approach more. Should we bake that into the $dcr shortcut?

Also, we either need to add the old versions to the matrix too or update the required checks in branch protection rules @chadwhitacre

[aminvakil]

If -T fixes things, I actually like this approach more. Should we bake that into the $dcr shortcut?

I'm not sure how it would act on older docker-compose versions or different parts which $dcr is getting used, I say let's not change everything everywhere :) (at least for now)

[BYK]

I say let's not change everything everywhere :) (at least for now)

Then please explain why that is needed on the kafka thing or revert that? 🤣

[aminvakil]

Last failed run was because of docker/compose#6704

[chadwhitacre]

Interesting, docker/compose#9035, which introduced the need for -T w/ 2.2.3, was the fix for #1133. Oh the tangled web we weave. 😂 😭

[chadwhitacre]

I dig it! 👍

[chadwhitacre]

👏 👏 @aminvakil as well as @BYK for wrestling this to the ground. It was supposed to be easy! 🙈

[aminvakil]

@BYK Thank you for helping me through this!
@chadwhitacre Thanks for merging!