[
https://issues.apache.org/jira/browse/HADOOP-20056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18136634#comment-18136634
]
ASF GitHub Bot commented on HADOOP-20056:
-----------------------------------------
Copilot commented on code in PR #8912:
URL: https://github.com/apache/hadoop/pull/8912#discussion_r4445667076
##########
.github/workflows/fork_ci_status.yml:
##########
@@ -0,0 +1,75 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+#
+
+# Mirror the contributor's fork workflow run as an informational check on the
+# upstream pull request. Contributors run build_and_test.yml in their own fork
+# (on `push` or `workflow_dispatch`); this bridge finds the run for the PR's
+# head branch and commit and reports it as the "Build" check.
+# See
https://github.com/apache/infrastructure-actions/tree/fork-ci/v1.0.0/fork-ci
+name: "Fork CI status"
+
+# Security: this privileged (checks: write) workflow is only triggered via
+# `schedule` and `workflow_dispatch`, so it always runs reviewed code from the
+# default branch and PR events cannot trigger it. It deliberately has no
Review Comment:
Unlike `schedule`, `workflow_dispatch` runs the ref selected by the
dispatcher, as `.github/workflow-security.md:145-147` also explains. There is
no default-branch guard here, so this workflow does not always run code from
the default branch. Please distinguish the two triggers in this security
comment rather than implying a restriction that is not enforced.
##########
.github/workflow-security.md:
##########
@@ -132,6 +138,18 @@ have a non-privileged workflow that you need to follow
with a privileged one. Th
Since they are privileged, though, you must be careful not to run untrusted
code or depend on untrusted variables.
+#### schedule and workflow_dispatch
+
+***privileged***
+
+`schedule` events run the workflow from the latest commit on the default
+branch. `workflow_dispatch` events run it on a branch chosen by the user who
+dispatches it, and only users with write access can do so. A pull request
+cannot trigger either of them, so the workflow code that runs has been
+reviewed. They can still hold secrets and a write token, so treat any data
Review Comment:
Not being PR-triggerable does not guarantee that the selected code has been
reviewed: a user with write access can manually dispatch an unreviewed branch.
Please describe the write-access trust boundary without asserting code review,
so this guidance does not imply that `workflow_dispatch` enforces a review
requirement.
> 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
> Labels: pull-request-available
> 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]
