Implement automatic rebuilds of release images#47
Implement automatic rebuilds of release images#47fatalbanana wants to merge 5 commits intorspamd:mainfrom
Conversation
- Generate a proper image for comparison - Put workflow parameters in their proper location
|
Should be done but I'm waiting to see it working on my fork yet ... |
There was a problem hiding this comment.
Pull Request Overview
This PR implements an automated security-driven rebuild system for release images. When vulnerabilities are detected in the current release image, the workflow automatically tests if rebuilding would resolve them, and if so, creates a new patch version tag to trigger a release.
Key changes:
- Replaces simple vulnerability scanning with an automated remediation workflow that rebuilds and re-tags images when fixes are available
- Adds workflow dispatch trigger to release workflow for programmatic triggering
- Introduces a reusable action for bumping patch version tags
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
.github/workflows/security.yml |
Transforms from passive scanning to active rebuild workflow with vulnerability comparison logic |
.github/workflows/release.yml |
Adds workflow_dispatch trigger to enable programmatic release initiation |
.github/actions/bump_tag/action.yml |
New composite action that increments patch version and triggers release workflow |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
| shell: bash | ||
| working-directory: ${{ github.workspace }} | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} |
There was a problem hiding this comment.
The github.token should be explicitly passed as an input to this composite action rather than being implicitly available. Composite actions don't automatically inherit secrets/tokens from the caller's context. This will likely fail with a permissions error when the action attempts to use gh CLI commands.
|
@fatalbanana want to note: better not only retag existing image, but each image should have maybe a couple of tags, one for rspamd version, and second for rspamd version + date for informative purposes and track when actually change was done. Also as improvement maybe better switch from hub.docker.com to ghcr.io? Reason is - very strict rate limits on images downloads from hub.docker.com for non authorized users... |
We might use github releases & publish some details there.
We should tell about both repos in the README. |
Use annotations on the image, that's what they're for and they have one specifically in the spec for that information. |
Creates new patch revisions when fixes become available (most likely via the base image).