You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
.github/workflows/publish-model-catalog.yml runs its generate job when the CI workflow completes (workflow_run). For that trigger the job's condition checks only that the triggering run succeeded and that github.event.workflow_run.head_branch == 'main', and then it checks out github.event.workflow_run.head_sha and runs install and generation scripts from it.
The branch name alone does not establish where that commit came from. The condition never checks which repository the triggering run belongs to, or that it was a push, so the job can end up checking out and running a commit that is not from this repository's own main.
Impact
Limited: generate runs with permissions: contents: read and no secrets, and the publish job (the only one with upload credentials) is separately gated to the upstream repository. It is still a trust boundary that should not rest on a branch name.
Expected (ideal state)
For the workflow_run trigger, generate (and anything that checks out workflow_run.head_sha) runs only when the triggering run is this repository's own push to main:
in addition to the existing conclusion == 'success' and head_branch == 'main'.
Acceptance criteria
The generate condition includes both checks above; schedule, workflow_dispatch and pull_request behaviour is unchanged.
No other workflow in this repository checks out workflow_run.head_sha without the same guard.
Other code-yeongyu repositories with workflow_run consumers were reviewed for the same pattern; they either check out a trusted ref (github.workflow_sha / main) or already require a push event, so this is the only instance found.
Activity
ci(publish-model-catalog): require a same-repository push for workflo…