Skip to content

Let the listing go up when the pictures did not - #603

Merged
andiwand merged 2 commits into
mainfrom
let-the-listing-go-up-without-its-pictures
Aug 18, 2026
Merged

Let the listing go up when the pictures did not#603
andiwand merged 2 commits into
mainfrom
let-the-listing-go-up-without-its-pictures

Conversation

@andiwand

@andiwand andiwand commented Aug 18, 2026

Copy link
Copy Markdown
Member

The listing job named screenshot-set in a plain needs:, which means 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, record tagged the
commit 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:

captured = !Dir.glob(File.join(FRAMED_DIR, "*", "*.png")).empty?
unless captured
  UI.important("no screenshots under #{FRAMED_DIR} - writing the listing text only")
  return false
end

with skip_upload_screenshots: !captured handing supply the answer, so the
store keeps the pictures it already has.

What changes

screenshot-set supplies the job rather than gating it.

  • if: ${{ !cancelled() && !inputs.dry_run && needs.upload.result == 'success' }}.
    !cancelled() is what takes the implicit success() off the needs:;
    needs.upload.result puts back the half that does have to hold, since a
    listing names a version code and there is no version code until the bundle is
    up.
  • The screenshot download runs only when there is a set to download. The
    artifact is written with if-no-files-found: error, so a screenshot-set
    that passed is the same answer as one that exists.
  • A ::warning:: when there are none, because the alternative is a release
    finishing 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: behaving
other than assumed is the whole of this bug. Three jobs of the same shape, run
both ways round:

upload screenshot-set listing
pictures fail success failure runs - fetch skipped, warning written, needs.screenshot-set.result reads failure
bundle fails failure success skipped, as before

actionlint is clean, and it does resolve the hyphenated needs.screenshot-set

  • a deliberate typo there is an error, so its silence means something.

What is still unproven is the same thing as before: no release has yet run these
jobs for real.

🤖 Generated with Claude Code

`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

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 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".

Comment thread .github/workflows/release.yml
…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
@andiwand
andiwand merged commit 466c319 into main Aug 18, 2026
7 checks passed
@andiwand
andiwand deleted the let-the-listing-go-up-without-its-pictures branch August 18, 2026 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant