[docker] Weekly rebuild of living tags#23352
[docker] Weekly rebuild of living tags#23352froozeify wants to merge 4 commits intoglpi-project:11.0/bugfixesfrom
Conversation
froozeify
force-pushed
the
11.0/docker-security-rebuild
branch
3 times, most recently
from
5549a92 to
47d1946
Compare
froozeify
force-pushed
the
11.0/docker-security-rebuild
branch
from
47d1946 to
e180a7b
Compare
|
I just don't recall if for this one i should also make a PR on main and 10.0 or if only in the default branch it will be triggered. |
| with: | ||
| script: | | ||
| const isSecurityRebuild = | ||
| context.payload.schedule === '0 3 * * 0' || |
There was a problem hiding this comment.
I do not like this check. Indeed, we may want to change the schedule in the future, and if we forgot to change this, we will break scheduled security rebuilds.
IMHO, it would be safer to have a unique schedule, and to have a isSecurityRebuild = context.github.event_name === 'schedule'.
For manual execution, we could have two inputs for manual displatch : "Rebuild nightly images? Yes/No" and "Rebuild latest stable images? Yes/No".
Then we could generate the matrix like this:
const mustRebuildStable =
context.payload.event_name === 'schedule'
|| context.payload.inputs?.['rebuild-stable'] === 'true';
const mustRebuildNightly =
context.payload.event_name === 'schedule'
|| context.payload.inputs?.['rebuild-nightly'] === 'true';
if (mustRebuildStable) {
// push latest stable tags into the matrix (with no-cache: true)
}
if (mustRebuildNightly) {
// push nighlty builds
}
| const tags = await github.rest.repos.listTags({ | ||
| owner: context.repo.owner, | ||
| repo: context.repo.repo, | ||
| per_page: 100, | ||
| }); | ||
|
|
||
| // Tags are ordered by creation (newest first), only keep stable tags (i.e: 11.0.6, not 11.0.6-rc1) | ||
| const stableTags = tags.data | ||
| .map(t => t.name) | ||
| .filter(name => /^\d+\.\d+\.\d+$/.test(name)); |
There was a problem hiding this comment.
It is probably safer to rely on the releases endpoint and filter to keep only entries matching "draft": false`` and "prerelease": false`.
You can then get the tag_name of each release.
| // Find the first stable tag that begins with the Major.Minor prefix (i.e: 11.0) | ||
| const latestVersionTag = stableTags.find(t => t.startsWith(`${supportedVersion}.`)); |
There was a problem hiding this comment.
Are you sure tags are correctly sorted at this moment?
| return; | ||
| } | ||
|
|
||
| core.info(`Security rebuild targets: ${latestPerMinorVersion.map(m => m.version).join(', ')}`); |
There was a problem hiding this comment.
| core.info(`Security rebuild targets: ${latestPerMinorVersion.map(m => m.version).join(', ')}`); | |
| core.info(`Rebuild targets: ${latestPerMinorVersion.map(m => m.version).join(', ')}`); |
2 participants
Rename and update the nightly docker workflow to rebuild the living tags.
Doing this will ensure that the latest images i.e 11.0.6 and 10.0.24 to have security fixes applied.
CVE are often discovered and fixed on the base image, the docker_rebuild script will update the base image (the glpi code downloaded will still be based on the release tag)
Related docker-image PR (should be merged first): glpi-project/docker-images#283
Using actions/github-script making it easy to call github api and also update ci summary <3
We shoudn't need to update anymore this file as it now guess the branch and release name (build is done on the last 2 major release, so currently 10 and 11. Using github release api)
Github don't display the file has being renamed :(
Nightly build (with one with debug enabled)
https://github.com/froozeify/glpi/actions/runs/22710991980
https://github.com/froozeify/glpi/actions/runs/22844220754
Living tags build
https://github.com/froozeify/glpi/actions/runs/22710941789
https://github.com/froozeify/glpi/actions/runs/22844248172