Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: remove docker-compose v1 tests #18688

Closed
Luap99 opened this issue May 25, 2023 · 9 comments
Closed

CI: remove docker-compose v1 tests #18688

Luap99 opened this issue May 25, 2023 · 9 comments
Assignees
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@Luap99
Copy link
Member

Luap99 commented May 25, 2023

From https://docs.docker.com/compose/:

Compose V1 no longer receives updates and will not be available in new releases of Docker Desktop after June 2023.

Given that I think it doesn't make sense to test it any more and we can safe some CI resources. We will continue to test compose v2.

cc @mheon @cevich @edsantiago

@vrothberg
Copy link
Member

I think we need to continue testing and making sure we're not regressing. Usage tends to go far beyond EOL dates. The latest Fedora 38, for instance, is still shipping 1.29.2.

@mheon
Copy link
Member

mheon commented May 25, 2023

IMO, we should add a comment to the v1 tests that they are deprecated (as upstream is also deprecated), but leave them around until they become a maintenance burden or start failing (at which point someone presumably notices the comment and removes them rather than fixes them)

@Luap99
Copy link
Member Author

Luap99 commented May 25, 2023

First, removing the tests doesn't mean it stops working all of the sudden. I am not worried that we manage to add changes that only break compose v1 but compose v2 tests plus all the other API tests we have still pass.

Second, it is already extra maintenance burden. Every single test that uses names has to do something like this:

expected="Recreating uptwice_app_1 ... ${CR}${NL}Recreating uptwice_app_1 ... done$CR"
if [ "$TEST_FLAVOR" = "compose_v2" ]; then
expected="Container uptwice-app-1 Recreate${NL}Container uptwice-app-1 Recreated${NL}Container uptwice-app-1 Starting${NL}Container uptwice-app-1 Started"
fi

The cycle for me was always test locally, which worked, then push changes then notice it fails due different naming.
Sure we do not add many tests there, but this is one of the reasons why I did not add more. I always had to spend extra time because I always have to test two different versions.

@cevich
Copy link
Member

cevich commented May 25, 2023

Only thing I'll add is that this task is enabled on many release-branches. So disabling it on main (and for new releases) may not be too bad. Presumably anybody using it is also on an older platform. Since it's deprecated, I think stripping it from main is probably fine. Thanks for thinking of this Paul.

@github-actions
Copy link

A friendly reminder that this issue had no activity for 30 days.

@Luap99
Copy link
Member Author

Luap99 commented Jun 26, 2023

The lasted docker compose v1 version was released over two years ago. I don't think it makes sense for us to test EOL software just because it is still shipped in Fedora.

@cevich cevich self-assigned this Jun 26, 2023
cevich added a commit to cevich/podman that referenced this issue Jun 27, 2023
Fixes containers#18688

Docker compose v1 has long since gone EOL and is no longer supported by
upstream.  Therefore the only things we're accomplishing by testing it
with modern Podman are: Wasting time and inviting flakes.  Remove it.

Also assert the v2-only support in the test `README.md` and remove all
v1-related conditionals.

Signed-off-by: Chris Evich <[email protected]>
@cevich
Copy link
Member

cevich commented Jun 29, 2023

Paul commented in #19000

Based on the other compose discussion yesterday I like to change my opinion. I think we can live with these test a bit longer until we know it is no longer in use (e.g. not shipped in fedora).

I hate to leave this issue open for 6+ months until (presumably) F39 comes out and drops the package. Any objections to closing it (which may risk forgetting about the idea)?

@Luap99
Copy link
Member Author

Luap99 commented Jun 29, 2023

You will notice when your VM images build break I assume?

@Luap99 Luap99 closed this as completed Jun 29, 2023
@cevich
Copy link
Member

cevich commented Jun 29, 2023

You will notice when your VM images build break I assume?

Ahh right, good point. Yep, that will be a great indication. Thanks.

@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 27, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 27, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants