workflows: rebuild branch containers on a schedule

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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

[BKPepe]

The -openwrt-24.10 container 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 update inside 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.yml is 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 for main and the maintained release branches and skips the build jobs, so scheduled runs stay identical to manual ones (a schedule event carries no ref input). GITHUB_TOKEN should be sufficient to create the workflow_dispatch events, 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.yml with ref=openwrt-24.10 (and ideally ref=openwrt-25.12) by hand? Dispatching requires admin rights, so I cannot do it myself.

References

• Stale branch tags on Docker Hub (last pushed 2025-12-14): https://hub.docker.com/r/openwrt/rootfs/tags?name=openwrt-24.10 — compare with the fresh release tags: https://hub.docker.com/r/openwrt/rootfs/tags?name=24.10.8
• kmods directories currently published for the 24.10 snapshot: https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/
• URL the stale containers try to fetch (404): https://downloads.openwrt.org/releases/24.10-SNAPSHOT/targets/x86/64/kmods/6.6.119-1-484466e2719a743506c36b4bb2103582/Packages.gz
• Example failing runtime-test job: https://github.com/openwrt/packages/actions/runs/31582252104/job/94072840557

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[BKPepe]

@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.

[aparcar]

Why is this in its own file instead of the workflow it's actually triggering?

[BKPepe]

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