post-merge.yml: the report job is skipped when the gate fails, so a red main opens no issue

Open Beginner friendly
  • Is something wrong?
#1,611 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, yaml
Domain
ci-cd

Research direction

Start in .github/workflows/post-merge.yml and read the if: condition on the report job, which depends on gate and so is skipped when gate fails. Check the GitHub Actions rules for implicit status-check functions in job conditions, then confirm the expected behaviour against AGENTS.md's background-testing rule. Done means a failing gate run executes report and opens or comments on the rolling issue, a later green run closes it, and cancelled or cut-skipped runs still report nothing. The PR will be read rather than built and needs maintainer review.

Written by the indexing model from the issue text.

Description

area:build bug effort:low P5 source:agent

What happens: post-merge run 43535610115 (push to main at 745edc36a) ended with job gate = failure and job report = skipped. The rolling issue main is red (post-merge gate) was not opened or commented on.

Expected: AGENTS.md "Fixes are tested in the background": a red post-merge gate opens or comments on the rolling issue; the next green run closes it.

Cause (read from .github/workflows/post-merge.yml on main): the report job has needs: gate and an if: with no status-check function:

if: ${{ (needs.gate.result == 'success' || needs.gate.result == 'failure') && needs.gate.outputs.skipped != 'true' && (...) }}

GitHub Actions adds an implicit success() to a job's if unless it contains always(), failure(), cancelled() or !cancelled(). With a failed needs job the implicit success() is false, so the job is skipped before the expression is read. The job therefore only ever runs on green.

Suggested fix: start the condition with always() && (the rest already excludes cancelled and skipped runs). One line.

Note on this particular run: its only red test was a_lowered_cap_refuses_the_same_face_at_once (crates/app/tests/import_step_guard.rs, "not within 30s"), the wall-clock flake of issue 1605, so main was not truly red here. The reporting gap is real for any failure.

A .github/ change: the PR is read, not built, and waits for the maintainer (needs-maintainer). Process change: yes does not apply (.github/ is not a process file).

Found by the maintenance session while watching runs.

Done means: a post-merge run whose gate fails runs report and opens or comments on the rolling issue; a green run after it closes that issue; a cancelled or cut-skipped run still reports nothing.

Dominant language
Rust
Stars
8
Forks
11
Avg merge
7h 10m
Merged PRs (30d)
740

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NeoTech/Camcraft

All issues in NeoTech/Camcraft

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.