workflows: rebuild branch containers on a schedule - #208
Merged
Conversation
Member
Author
|
@aparcar Please can you take a look what is going on? We have broken CI/CD for stable branches in the packages feed for a few months already. |
BKPepe
force-pushed
the
scheduled-rebuilds
branch
from
August 16, 2026 08:45
c4fa8a0 to
d328d30
Compare
Member
|
Why is this in its own file instead of the workflow it's actually triggering? |
The rootfs, sdk and imagebuilder containers for the release branches are only rebuilt when someone triggers containers.yml by hand. The -openwrt-24.10 tags on Docker Hub were last pushed in December 2025 with kernel 6.6.119 baked in, while the 24.10-SNAPSHOT feeds have moved on to 6.6.151, so every runtime test in the packages CI fails with a 404 on the kmods feed. Add a schedule trigger: a scheduled run only dispatches the workflow for main and the maintained release branches and skips the build jobs. Going through workflow_dispatch keeps scheduled runs identical to manual ones, since a schedule event carries no ref input and the rest of the workflow is driven by it. GITHUB_TOKEN may create workflow_dispatch events, so no extra secrets are needed.
BKPepe
force-pushed
the
scheduled-rebuilds
branch
from
August 17, 2026 07:49
d328d30 to
5c4901d
Compare
Member
Author
|
Okay, good suggestion! Reworked. Hopefully, it is okay now. Verified in my fork that the schedule path dispatches the three branch runs and skips the build jobs: https://github.com/BKPepe/docker/actions/runs/32011045091 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The
-openwrt-24.10container tags on Docker Hub were last pushed on 2025-12-14 with kernel 6.6.119 baked in. The 24.10-SNAPSHOT feeds have since moved to kernel 6.6.151, and the old kmods directories were removed from the download server. As a result,opkg updateinside the containers fails with a 404 on the kmods feed.This currently breaks the runtime-test phase of openwrt/packages PRs against openwrt-24.10 (see e.g. openwrt/packages#30260, where the package compiles on all architectures but the runtime tests fail with a 404).
containers.ymlis only triggered manually, and release-tag dispatches do not refresh the branch snapshot tags, so the branch containers can become stale until someone manually rebuilds them.Add a schedule trigger to
containers.yml: a scheduled run only dispatches the workflow formainand the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (ascheduleevent carries norefinput).GITHUB_TOKENshould be sufficient to create theworkflow_dispatchevents, so no additional secrets are needed. The cron and the branch list can be adjusted as needed.In the meantime, could a maintainer please dispatch
containers.ymlwithref=openwrt-24.10(and ideallyref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.References