Skip to content

Unblock required-workflow source repository PRs without weakening organization gates #732

Description

@seonghobae

Incident

The organization ruleset requires the OpenCode and Noema workflows sourced from ContextualWisdomLab/.github, and the ruleset also targets the .github repository's own default branch. A central bootstrap repair therefore cannot currently satisfy the two workflow contexts sourced from the same repository.

Exact example: PR #731, head c73ee47861fca21e6959ce80fdf57b434c715c9d.

  • all eight repository-owned exact-head workflows have successful runs on the unchanged head: CodeQL, Semgrep, Security Scan, Python Security, OSV, Scorecard, Secret Scan, and SBOM;
  • auto-merge is enabled;
  • direct guarded merge reports: 2 of 15 required status checks are expected and New changes require approval from someone other than the last pusher;
  • no OpenCode or Noema review/check was published after a fresh ready-for-review PR was opened on the exact head;
  • comments requesting both reviewer Apps produced no review because their execution is workflow-driven.

GitHub's documented source-repository boundary

GitHub's ruleset troubleshooting documentation calls out required-workflow source repositories explicitly. For workflows intended to run through a ruleset, GitHub recommends choosing a deliberate source-repository configuration, such as adding an unconditional job condition, disabling the local workflow in the source repository, or disabling Actions there. It also recommends Evaluate mode or an authorized bypass for bootstrap situations where the required workflow cannot run.

Primary documentation:

Required administrative decision

Choose and implement one fail-closed pattern for the .github source repository:

  1. exclude only ContextualWisdomLab/.github from the organization required-workflow targets while keeping its direct CodeQL/Semgrep/Security/Python/OSV/Scorecard/Secret/SBOM checks plus independent review rules; or
  2. put the required-workflow rules in Evaluate mode long enough to merge the validated bootstrap repair, then return them to Active after proving they execute; or
  3. configure the source repository/local workflow behavior according to GitHub's supported-directory guidance so the same OpenCode/Noema contexts are actually emitted for .github PRs.

Do not synthesize statuses, remove independent review, or weaken the organization rules for target application repositories.

Acceptance evidence

Activity

  1. seonghobae commented on Aug 4, 2026

    @seonghobae
    ContributorAuthor

    Fresh evidence on 2026-08-04: #731 is back on its clean exact source head c73ee47861fca21e6959ce80fdf57b434c715c9d. Seven of the eight direct PR workflows have a fresh successful run; the remaining CodeQL run is queued, while earlier exact-head CodeQL runs are successful. A guarded merge still reports New changes require approval from someone other than the last pusher plus four unsatisfied required contexts, including one expected ruleset workflow. GitHub's ruleset troubleshooting guidance also says ruleset workflows should not use cancel-in-progress; both current OpenCode and Noema entrypoints do. The source-repository configuration/evaluate-mode decision remains necessary before the clean bootstrap can merge without synthesizing statuses.

  2. self-assigned this
    on Aug 4, 2026
  3. added
    area: apiAPI, protocol, event, or external contract
    area: authAuthentication, authorization, identity, or tenant isolation
    area: ci-cdCI, GitHub Actions, checks, release, or supply chain
    area: securitySecurity boundary, hardening, or vulnerability prevention
    status: triagedOpen issue has an organization taxonomy assignment
    type: featureNew or expanded product capability
    on Aug 22, 2026
  4. seonghobae commented on Aug 28, 2026

    @seonghobae
    ContributorAuthor

    Fresh source-repository canary for the existing bootstrap/review deadlock, without changing ownership or requesting bypass.

    Current protected central source: .github/main@24ee38b097dbfc1a895e1199ade48cff36431d05.
    Current repair consumer: .github#897@4553da875f2799b39e1c89aeb89f552d9fb92564, Ready and mechanically mergeable against that exact base.

    The product/security repair itself is exact-head GREEN: Security Scan 33141727347, dependency-review job 98753825077, checked out and verified the submitted head, the support probe succeeded, and the pinned Dependency review action executed success rather than being skipped.

    The first remaining causal boundary is now the source-repository review path: required OpenCode run 33141725355, job 98755817116, fails closed because no authenticated APPROVED or CHANGES_REQUESTED OpenCode review is anchored to current head 4553da8.... The formal review inventory contains only predecessor-head OpenCode verdicts; none may transfer. A fresh @opencode-agent exact-head request has been posted on #897 and has not yet produced a current-head formal verdict.

    RED acceptance for #732: an unchanged, technically clean .github source-repository PR can still reach the required OpenCode workflow with no current-head Reviews-API verdict, leaving the bootstrap repair non-integrable.

    Smallest safe remedy/GREEN: make the supported central source-repository review/dispatch path emit a genuine exact-current-head formal verdict for 4553da8... (and the corresponding required context) under the existing reviewer identity and permissions. Do not synthesize a status, transfer a predecessor review, self-approve, use admin/ruleset bypass, or weaken the independent-review requirement. After that, refetch all current-head checks/reviews before any normal integration decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area: apiAPI, protocol, event, or external contractarea: authAuthentication, authorization, identity, or tenant isolationarea: ci-cdCI, GitHub Actions, checks, release, or supply chainarea: securitySecurity boundary, hardening, or vulnerability preventionbugSomething isn't workingpriority: mediumNormal-priority or P2 workstatus: triagedOpen issue has an organization taxonomy assignmenttype: bugDefect or incorrect behaviortype: featureNew or expanded product capability

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions