Let the listing go up when the pictures did not - #603
Merged
Conversation
`listing` named `screenshot-set` in a plain `needs:`, so a screenshot run that wedged an emulator did not cost the release its pictures - it skipped the job outright and cost the release its store copy and this version's release notes as well. The bundle went up, the tag and the draft were written, and the one job that tells play what the release says never ran. The lane was already written for the other outcome: `stage_screenshots` answers "no screenshots under fastlane/framed - writing the listing text only" and hands `skip_upload_screenshots` on to supply, which leaves the pictures the store has where they are. Nothing ever reached it. So `screenshot-set` supplies the job rather than gating it. `!cancelled()` is what takes the implicit `success()` off the `needs`, and `needs.upload.result` puts back the half that has to hold: a listing names a version code, and there is no version code until the bundle is up. Checked on a branch of its own rather than reasoned about, both ways round, since a `needs:` behaving other than assumed is what this commit is about: - `screenshot-set` failing -> `listing` runs, the fetch step is skipped, the warning is written, and `needs.screenshot-set.result` reads `failure`. - `upload` failing -> `listing` is skipped, as before. The warning is there because the alternative is a release finishing green over a listing still showing the pictures of some earlier version. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UBGYtacAAsAiA19UJGvdXb
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c8724a34dd
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
…vites the question "Re-run failed jobs" re-runs what failed and everything downstream, so a repaired screenshot job carries `screenshot-set` and `listing` with it and the pictures go up in a second edit against the same version code - which the internal track allows for as long as the release sits on it. Checked on a branch of its own, both halves of it: the listing really does run again and reads `screenshot-set` as `success`, and the device that passed the first time is not photographed twice - its artifact carries over from the earlier attempt and the two halves merge as they would have. The job list reports `run_attempt` 2 for jobs that never re-executed, so that field is not the thing to read. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UBGYtacAAsAiA19UJGvdXb
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
listingjob namedscreenshot-setin a plainneeds:, which means ascreenshot run that wedged an emulator did not cost the release its pictures -
it skipped the job outright and cost the release its store copy and this
version's release notes as well. The bundle went up,
recordtagged thecommit and drafted the release, and the one job that tells Play what the release
says never ran. Green run, half a release.
The Fastfile was already written for the other outcome and never reached:
with
skip_upload_screenshots: !capturedhanding supply the answer, so thestore keeps the pictures it already has.
What changes
screenshot-setsupplies the job rather than gating it.if: ${{ !cancelled() && !inputs.dry_run && needs.upload.result == 'success' }}.!cancelled()is what takes the implicitsuccess()off theneeds:;needs.upload.resultputs back the half that does have to hold, since alisting names a version code and there is no version code until the bundle is
up.
artifact is written with
if-no-files-found: error, so ascreenshot-setthat passed is the same answer as one that exists.
::warning::when there are none, because the alternative is a releasefinishing green over a listing still showing an earlier version's pictures.
Nothing else moves: the release stays coupled to the screenshots, and the hour
they take is still on its critical path.
How it was checked
On a throwaway branch rather than by reading the docs, since a
needs:behavingother than assumed is the whole of this bug. Three jobs of the same shape, run
both ways round:
uploadscreenshot-setlistingneeds.screenshot-set.resultreadsfailureactionlintis clean, and it does resolve the hyphenatedneeds.screenshot-setWhat is still unproven is the same thing as before: no release has yet run these
jobs for real.
🤖 Generated with Claude Code