Repository navigation
Conversation
github-actions
Bot
added
kind:bug
Saibernard
left a comment
Saibernard
left a comment
There was a problem hiding this comment.
I checked this against the run history and the bucket. The condition is right!
The upload did run once since August. On 6 November a cold imx9 cache made the seed job run (run 42244062992) and it uploaded, so the master build on S3 is from that day now.
Tags cut from main are affected as well. filter_cold_seeders.py probes the main cache scope for every ref, so a tag made after #28278 finds a warm cache, skips the seed and loses the S3 upload and the GitHub release upload with it, that step is in the same job. v1.18.0-rc1 only seeded because release/1.18 branched before #28278 and its seed job has no condition. Could you update the description for these two?
And deploy-aws isn't quite the same condition, it uses always(). The deploy job in dev_container.yml is the exact match if you want to point at one.
|
Thanks for checking this against the run history and the bucket. All three points are right, and I confirmed each one:
I updated the description for all three. The commit message repeats two of the same statements (the |
|
I'll take a look. |
|
Thanks for updating it! Yes, I'd reword the commit as well so it matches the description. |
Since the seed stage became conditional (PX4#28278), it is skipped on every push where all chip family caches are already warm, which is almost every push to main. The artifacts job had no status function in its condition, so GitHub applied an implicit success(), which is false when any upstream job was skipped. Since then Upload Artifacts has only run on main when a seeder happened to run (once, on 2026-11-06, when the imx9 cache was cold). Version tags cut from main are affected the same way. filter_cold_seeders.py probes the main cache scope for every ref, so such a tag skips the seeders and loses both the S3 upload and the draft GitHub Release, which is a step of the same job. Check the build result explicitly, as the deploy job in dev_container.yml already does. Assisted-by: Claude:claude-opus-5-5 Signed-off-by: YoungjuKim <[email protected]>
f096e04 to
52ed7a6
Compare
|
Done. I reworded the commit (now 52ed7a6) so it matches the description: the one upload on 2026-11-06, tags cut from |
Solved Problem
Since #28278, the Upload Artifacts job of Build all targets is skipped on every push where no seeder runs. On
mainthat is almost every push, soFirmware/master/on S3 (the developer firmware QGC offers) went without an update from 2026-08-18 to 2026-11-06, and has not been updated by any later push.#28278 made the
seedstage conditional onhas_cold. On a normalmainpush every family cache is warm, so all seeders are skipped.setupcopes with that through!failure() && !cancelled(), butartifactshas no status function in itsif:, so GitHub adds an implicitsuccess(), and that is false when any upstream job was skipped (actions/runner#491, actions/runner#2205).The run history shows when it started:
mainpush before ci(build-all): seed ccache only for chip families with cold caches #28278): seeders ran, Upload Artifacts successmainpush run after that, more than 300 of them up to 38910006968 on 2026-10-16, shows the same result: seeders skipped, upload skipped.Seed [imx9]run, so Upload Artifacts ran and succeeded.https://px4-travis.s3.amazonaws.com/Firmware/master/px4_fmu-v6x_default.px4reportedLast-Modified: Tue, 18 Aug 2026 18:02:20 GMT(the end of run 32166883191) until that run, and now reportsFri, 06 Nov 2026 16:14:59 GMT.Version tags cut from
mainare affected as well.filter_cold_seeders.pyprobes therefs/heads/maincache scope for every ref (this workflow does not setSEEDER_PROBE_SCOPE), so a tag made after #28278 finds warm caches and skips the seeders. It then loses both the S3 upload and the draft GitHub Release, because Upload Artifacts to GitHub Release is a step of the sameartifactsjob. v1.18.0-rc1 (34518662756) still seeded and uploaded only becauserelease/1.18branched before #28278, and itsseedjob has no condition.Solution
Give
artifactsan explicit condition,!cancelled() && needs.setup.result == 'success' && (<existing branch/tag check>). This is the same condition thedeployjob indev_container.ymluses. The job still only runs when every build leg succeeded. A failed seeder still stops it, becausesetupis then skipped. PR builds are unchanged because their branch name ispr-<N>.Changelog Entry
For release notes:
Alternatives
Adding
always()alone would also let the job start, but it would upload even when a build leg failed. Checkingneeds.setup.resultkeeps the old "upload only when every build succeeded" rule.Test coverage
I could not run the changed workflow myself, because the upload job only runs on pushes to this repository. The first
mainpush after merging should show Upload Artifacts running and a newLast-Modifiedon the S3 objects, and the next version tag should create its draft GitHub Release again.Context
actions/runner#491, actions/runner#2205 (implicit
success()with skipped needs).Assisted-by: Claude:claude-opus-5-5