Skip to content

containers/ws: Publish image more frequently, only when needed #22042

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

Merged

Conversation

marvinruder
Copy link
Contributor

As mentioned in #21969 (comment), the current method of pushing new cockpit/ws images to the registry is not optimal, as an image is pushed in regular intervals regardless of whether the Cockpit version changed. To not push an excessive number of images, a weekly schedule has been adopted, so that the container releases can be up to 7 days late after a new release landed in the Fedora repositories (this has also been discussed in #21950).

This PR proposes the following changes:

  • Images are built every day.
  • The Cockpit version of the new image is compared against the image tags in the registry. If an image with that version is already present, the newly built image is redundant and will not be pushed.
  • To retain the capability of overwriting e.g. a corrupted image in the registry, a flag FORCE_PUSH for manual workflow dispatches has been added. If set to true, the image will be pushed to the registry regardless of whether an image with the current version is already present.

Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you! In our defence, the regular rebuilds were somewhat intended to pick up security updates etc. from the distro even if cockpit didn't change. But we release often enough that this doesn't matter so much, and cockpit is the primary attack vector anyway. So I agree to this change.

Let's just fix the version check. Also, can you please reorder the commit subject to "containers/ws: Publish image..."?

* Change cron schedule to daily
* Compare current version to tags in registry, skip push if match found
* Force push image if workflow dispatched manually with input set

Signed-off-by: Marvin A. Ruder <[email protected]>
@marvinruder marvinruder force-pushed the publish-ws-image-only-when-needed branch from 03cd772 to f64a1f6 Compare May 26, 2025 08:23
@marvinruder
Copy link
Contributor Author

Thank you! In our defence, the regular rebuilds were somewhat intended to pick up security updates etc. from the distro even if cockpit didn't change.

Ah, I see.

But we release often enough that this doesn't matter so much, and cockpit is the primary attack vector anyway.

Also, in case some major vulnerability in the base image is found, you can still publish a new image immediately using the FORCE_PUSH parameter.

So I agree to this change.

Let's just fix the version check. Also, can you please reorder the commit subject to "containers/ws: Publish image..."?

All done, thanks!

@martinpitt martinpitt changed the title Publish cockpit/ws image more frequently, only when needed containers/ws: Publish image more frequently, only when needed May 26, 2025
Copy link
Member

@martinpitt martinpitt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool, thanks! GitHub currently has an outage, so will have to prod the tests a bit.

@martinpitt martinpitt added the .github-changes Set by a reviewer just before landing to acknowledge that a PR changes github workflows label May 26, 2025
@martinpitt martinpitt merged commit 7fb5a6e into cockpit-project:main May 26, 2025
33 of 37 checks passed
@marvinruder marvinruder deleted the publish-ws-image-only-when-needed branch May 26, 2025 09:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
.github-changes Set by a reviewer just before landing to acknowledge that a PR changes github workflows
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants