kaxil opened a new pull request, #70645:
URL: https://github.com/apache/airflow/pull/70645

   Follow-up to #70618.
   
   ## Summary
   
   Both jobs in `registry-build.yml` are gated on
   [`github.event_name == 'workflow_call' || <committer 
allowlist>`](https://github.com/apache/airflow/blob/9595a58c01/.github/workflows/registry-build.yml#L82-L99),
   which reads as "skip the allowlist when another workflow calls us". That 
disjunct never fires.
   Per the [reusable-workflow 
docs](https://docs.github.com/en/actions/reference/workflows-and-actions/reusable-workflows),
   "when a reusable workflow is triggered by a caller workflow, the `github` 
context is always
   associated with the caller workflow" -- so `github.event_name` reports the 
caller's event
   (`workflow_dispatch`), never `workflow_call`. That same rule is why
   `github.event.sender.login` resolves to the caller's dispatcher here at all; 
the file cannot
   have one behaviour without the other.
   
   So the allowlist in this file is enforced on the `workflow_call` path too, 
against a copy
   that has drifted from the one on
   
[`build-info`](https://github.com/apache/airflow/blob/9595a58c01/.github/workflows/publish-docs-to-s3.yml#L106-L121)
   in `publish-docs-to-s3.yml`. That list also carries `vatsrahul1001`, who 
dispatched 7 of the
   last 40 docs publishes. A provider wave they dispatch would publish the docs 
and silently
   skip the registry update -- no failure, just a registry that quietly stops 
matching what is
   on the site.
   
   ## Design rationale
   
   **Why a new input rather than syncing the two lists.** Syncing re-arms the 
same trap: the
   next name added to the docs allowlist breaks the registry again, silently, 
and nothing
   fails to point at it. Gating on an input declared only under `workflow_call` 
removes the
   coupling instead -- each entry point governs its own dispatch, and there is 
no second copy
   to keep in step.
   
   **Why `default: true` instead of having the caller pass it.** A caller that 
forgets the
   flag would fall back to the sender allowlist, which is the same silent-skip 
failure in a
   quieter form. Defaulting to true means any current or future caller gets the 
right
   behaviour without opting in. Nothing else can set it: the input is 
undeclared on the
   `workflow_dispatch` path, so a standalone dispatch still evaluates it falsy 
and still
   enforces the allowlist. This is the same mechanism `ci-image-already-built` 
already relies
   on one field above.
   
   **Access is not widened in a way that matters.** `workflow_call` is only 
reachable from
   workflows in this repo, and each of those gates its own dispatch. Dropping 
the second check
   means the registry trusts the caller's allowlist rather than re-deciding 
with stale data.
   
   ## Gotchas
   
   The allowlists are still two separate literals -- Actions has no way to 
share one across
   workflow files without codegen or a composite action. The difference is that 
they no longer
   have to agree: each now governs only its own entry point, so drift stops 
being a bug.
   
   ## Not addressed here
   
   Two other things I raised on #70618 are design calls rather than fixes, so 
they are left
   for that thread:
   
   - The registry no longer waits on the docs publish, so it can put `/stable/` 
deep links on
     live for docs that never landed. The rationale for removing that gate is 
recorded in the
     [code 
comment](https://github.com/apache/airflow/blob/9595a58c01/.github/workflows/publish-docs-to-s3.yml#L633-L634),
     and restoring it cheaply means moving the two host-side sync steps into a 
job that needs
     `publish-docs-to-s3` -- worth doing, but not something to change 
unilaterally.
   - Docs-only publishes now pay the image export/stash round-trip for a stash 
only
     `build-docs` reads. That cost is inherent to splitting the build out: the 
stash is how
     `build-docs` receives the image, so it cannot simply be made conditional.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to