[
https://issues.apache.org/jira/browse/HADOOP-20056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136610#comment-18136610
]
ASF GitHub Bot commented on HADOOP-20056:
-----------------------------------------
GauthamBanasandra opened a new pull request, #8912:
URL: https://github.com/apache/hadoop/pull/8912
### Description of PR
ASF Infra disables `pull_request_target` for ASF repositories from November
2026
(https://infra.apache.org/github-actions-policy.html). Hadoop uses it to
create the "Build" check
on PRs, which mirrors the contributor's fork run of `build_and_test.yml`:
- `notify_test_workflow.yml` (`pull_request_target`) finds the fork's push
run and creates the check.
- `update_build_status.yml` (cron every 15 minutes) PATCHes it until the run
completes.
Without a replacement, PRs lose the "Build" check. This PR replaces both
workflows with
`fork_ci_status.yml`, which calls ASF Infra's
[fork-ci](https://github.com/apache/infrastructure-actions/tree/fork-ci/v1.0.0/fork-ci)
action
(`fork-ci/v1.0.0`, pinned to `36e391618baf31f50c5a7a7347faf00cba6cf085`):
- **Triggers:** `schedule` every 10 minutes on odd minutes (`7,17,...,57`)
plus `workflow_dispatch`.
There is no `pull_request_target`, and no `workflow_run` either:
SECURITY.md disallows it and
zizmor flags it (`dangerous-triggers`). The cost is latency. A new PR's
check appears on the next
scheduled run (typically within 10-20 minutes, since GitHub often delays
scheduled runs) rather
than within seconds of opening the PR.
- **Token:** job-level `actions: read`, `checks: write`, `pull-requests:
read`; workflow-level
`permissions: {}`. fork-ci reads API metadata only. It never checks out,
builds or downloads
anything from the PR or fork.
- **Scope:** guarded by `github.repository == 'apache/hadoop'`, one
serialized concurrency group
(`cancel-in-progress: false`), `ubuntu-slim`, 10-minute timeout.
- **Branches:** `base-branches: trunk`. Today trunk is the only branch with
`build_and_test.yml`;
branch-3.3.x, 3.4.x and 3.5.x do not have it. Add a release branch only
after the workflow lands there.
- `build_and_test.yml` gains `workflow_dispatch:` as fork-ci asks. A
contributor can then rerun the
build on their PR branch from their fork's Actions tab without pushing
again, and fork-ci mirrors
that run too.
- `.github/workflow-security.md` notes the `pull_request_target` removal,
documents the
`schedule`/`workflow_dispatch` triggers and describes the new bridge.
The two old workflows are deleted in this same PR so that two bridges never
write "Build" checks at
the same time.
#### Check name: kept as "Build"
- **For "Build":** contributors and committers already look for this name.
"Build (Windows)" (planned
for `build_and_test_windows.yml`) reads as its sibling. Nothing gates
merges on it, because
`.asf.yaml` has no required status checks.
- **Against "Build":** PRs that are open at cutover keep their legacy
"Build" check, which is no
longer updated, beside fork-ci's new "Build" check until the next push.
fork-ci never adopts or
overwrites the legacy check: it only updates checks whose `external_id` it
set itself
(`fork-ci:build_and_test.yml:pr:<n>`).
- **"Build (fork)"** would avoid that same-name overlap and put
"contributor-controlled" in the name.
But fork-ci already says that in every check summary, and the overlap
disappears on the next push.
Per the fork-ci README, renaming later creates a new check and leaves the
old one behind, so it is
better to decide now.
#### API budget
Today's `update_build_status.yml` checks every open PR on each run. Run
41221515991 covered 287
PRs and sent ~169 PATCHes: about 630 REST calls per run, ~2,500 per hour. It
succeeds, so the
repository's `GITHUB_TOKEN` limit is above that. fork-ci lists all open PRs
(3 pages for ~285)
but polls only a rotating group of 25 plus PRs updated in the last 6 hours:
roughly 100-150 calls
per run, ~600-900 per hour at 6 runs per hour. A full rotation over ~280
trunk PRs takes about 2 hours.
#### Follow-ups (not in this PR)
- `labeler.yml` (`pull_request_target`, unpinned `actions/checkout@v3`,
`actions/[email protected]`) and
`notify_cloud_aws.yml` (`pull_request_target`) must also be migrated
before the cutoff.
- `build_and_test_windows.yml` / "Build (Windows)": add a second fork-ci
step to `fork_ci_status.yml`
with its own `workflow`, `check-name` and `base-branches`, plus `if: ${{
!cancelled() }}`.
- `.github/workflows/images/workflow-enable-button.png` is now unused.
Legacy "action_required"
checks still embed its raw trunk URL, so it is left in place for now.
### How was this patch tested?
- actionlint 1.7.12: no findings in the changed workflows.
- zizmor 1.31.1, default persona with online audits (impostor-commit,
ref-confusion, etc. via the
GitHub API): `fork_ci_status.yml` has no findings, and it is also clean
under `--persona=pedantic`.
The only findings in `build_and_test.yml` are three pre-existing
`self-repository` help notes on
unchanged lines, identical to trunk. Repo-wide, findings drop from 125 to
116 (37 → 34 high),
because the deleted workflows used `pull_request_target` and unpinned
`actions/github-script@v9`.
- Checked that `apache/*` actions are implicitly trusted by
`allowlist-check`, which
`asf_allowlist_check.yml` (HADOOP-20050, #8906) runs on this PR. fork-ci's
nested
`actions/github-script@3a2844b7…` is the same pin Hadoop already uses.
- Not exercised live. The bridge only acts on PRs into apache/hadoop from
other repositories, so it
cannot run in a contributor fork as-is. After merge, a committer should run
`gh workflow run fork_ci_status.yml -R apache/hadoop` and confirm that a
"Build" check with a
"Fork run …" title and a link to the fork run appears on a recently pushed
PR. Then confirm that a
PR from a fork with Actions disabled gets "action_required" with setup
advice. The check is
informational, so reverting this PR is a safe rollback.
### For code changes:
- [x] Does the title of this PR start with the corresponding JIRA issue id
(e.g. 'HADOOP-17799. Your PR title ...')?
- [ ] Object storage: N/A
- [ ] New dependencies: none (fork-ci is an ASF Infra action)
- [ ] LICENSE/NOTICE: N/A
### AI Tooling
- [x] The PR includes the phrase "Contains content generated by Claude Code"
- [x] My use of AI contributions follows the ASF legal policy
https://www.apache.org/legal/generative-tooling.html
Contains content generated by Claude Code.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
> Replace the pull_request_target "Build" check bridge with ASF fork-ci
> ---------------------------------------------------------------------
>
> Key: HADOOP-20056
> URL: https://issues.apache.org/jira/browse/HADOOP-20056
> Project: Hadoop Common
> Issue Type: Bug
> Components: hadoop-common
> Affects Versions: 3.5.0
> Reporter: Gautham Banasandra
> Assignee: Gautham Banasandra
> Priority: Major
> Fix For: 3.5.0
>
>
> ASF Infra disables the {{pull_request_target}} trigger for ASF repositories
> from November 2026 ([ASF GitHub Actions
> policy|https://infra.apache.org/github-actions-policy.html]). ASF
> repositories cannot opt back in.
> Hadoop uses {{pull_request_target}} to put the "Build" check on pull
> requests. Contributors run {{build_and_test.yml}} in their own fork on
> {{push}}, and two upstream workflows mirror that run onto the PR:
> * {{notify_test_workflow.yml}} ({{pull_request_target}}) finds the fork's run
> and creates the "Build" check.
> * {{update_build_status.yml}} (cron, every 15 minutes) updates the check
> until the fork run completes.
> Once the trigger is disabled, PRs lose the "Build" check.
> h3. Proposal
> Replace both workflows with one schedule-driven bridge built on ASF Infra's
> [fork-ci
> action|https://github.com/apache/infrastructure-actions/tree/fork-ci/v1.0.0/fork-ci]
> ({{fork-ci/v1.0.0}}):
> * Add {{.github/workflows/fork_ci_status.yml}}. It is triggered only by
> {{schedule}} (every 10 minutes) and {{workflow_dispatch}}. It has no
> {{pull_request_target}} and no {{workflow_run}} trigger, which SECURITY.md
> disallows and zizmor flags as a dangerous trigger.
> * The job token has only {{actions: read}}, {{checks: write}} and
> {{pull-requests: read}}. The workflow is guarded to {{apache/hadoop}},
> serialized in one concurrency group, and runs on {{ubuntu-slim}} with a
> 10-minute timeout. The action is pinned by commit SHA.
> * fork-ci reads GitHub API metadata only. It never checks out, builds or
> downloads anything from the PR or the fork, and it writes only its own checks.
> * Keep the check name "Build". Mirror PRs against {{trunk}}, the only branch
> that currently has {{build_and_test.yml}}.
> * Add {{workflow_dispatch}} to {{build_and_test.yml}}, as fork-ci requires.
> Contributors can then rerun the build on their PR branch without pushing
> again.
> * Delete {{notify_test_workflow.yml}} and {{update_build_status.yml}} in the
> same change, so two bridges never write "Build" checks at the same time.
> * Update {{.github/workflow-security.md}} to describe the new bridge and the
> {{schedule}} / {{workflow_dispatch}} triggers.
> h3. Behaviour changes for contributors
> * A new PR's "Build" check appears on the next scheduled run, typically
> within 10-20 minutes, instead of right after the PR is opened.
> * If no fork run is found, the check is now "neutral" with setup advice
> instead of "action required". Disabled fork workflows still get "action
> required".
> * On PRs that are open at the cutover, the old "Build" check stops updating,
> and a new "Build" check appears beside it until the next push.
> h3. Out of scope (follow-ups)
> * {{labeler.yml}} and {{notify_cloud_aws.yml}} also use
> {{pull_request_target}} and need their own migration before the cutoff.
> * A "Build (Windows)" check for the planned {{build_and_test_windows.yml}}
> can be added later as a second fork-ci step in the same workflow.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
