Repository navigation
[CI][Crossbow] Use apache/arrow instead of separated repository (e.g. ursacomputing/crossbow) #46014
Description
Describe the enhancement requested
We didn't have enough GitHub Actions capacity when we develop Crossbow. So using separated repository (and separated CI services such as Azure Pipelines and Travis CI) was reasonable.
But we have enough GitHub Actions capacity recently. Can we reconsider the Crossbow approach?
We may be able to use on.workflow_dispatch and gh wokrflow run --ref as an alternative of the current Crossbow approach.
Some inconvenient points for the current Crossbow approach:
- CI results use a GitHub comment (example) instead of GitHub status checks.
- It may cause a long history.
- No direct link to artifacts.
- Crossbow creates a new tag for each job and uses GitHub Release associated with the tag for artifacts. There is no direct link for the associated GitHub Release.
- We can't use Dependabot for
dev/tasks/*/*.yml - Difficult to automate job submission.
- For example, we want to submit binary artifacts build jobs after source archive build is completed automatically in release process.
- FYI: We already have
secrets.GITHUB_CROSSBOW_TOKENin apache/arrow GitHub Actions. So we will be able to implement it with the current Crossbow approach.
- ...
Component(s)
Continuous Integration, Developer Tools
Activity
amoeba commentedon Apr 4, 2025
In case it helps, Datafusion just implemented something like this, see https://github.com/apache/datafusion/blob/main/.github/workflows/pr_comment_commands.yml for how they did it.
kou commentedon Apr 5, 2025
Wow! I didn't know it!
kszucs commentedon Apr 8, 2025
I have been thinking of the same recently, we could take advantage of additional GHA features though I have some questions:
In an ideal setup we could easily create a release by:
kou commentedon Apr 9, 2025
https://infra.apache.org/github-actions-policy.html has the following:
2025-04-01/2025-04-08 statistics: https://github.com/apache/arrow/actions/metrics/usage?dateRangeType=DATE_RANGE_TYPE_CUSTOM&range=1743465600000-1744070400000
Total minutes: 77,900
Currently, we only use GitHub Actions and Azure Pipelines. So we'll be able to port all jobs to GitHub Actions.
We'll try self-hosted runners or we mark these architectures as tier 2 or tier 3 platforms. See also: #46002
I hope that
git tag && git pushcan trigger all of them (build source archive, sign it, upload it, build binary artifacts from it, sign them, upload them, verify them, start a vote, ...) with Automated Release Signing. :-)assignUser commentedon May 12, 2025
Yes, I have discussed this last year with @raulcd too and while it will be a bunch of work to port everything over the benefits outweigh that effort.
There is an infra page that shows the metrics in a format matching the policy.
We could potentially even port the benchmark jobs but that comes with additional considerations in regards to noisiness of the results.
I don't mind triggering it via the actions tab but either way automatic signing will be great!
assignUser commentedon May 12, 2025
As a caveat: runs triggered with 'workflow_dispatch' have full permissions and secret access by default, so the jobs have to be carefully checked for minimal permissions, no secret use and they can never be run using the pr version of the workflow.
I think I'd prefer that we don't trigger these via comment but rather have the reviewer trigger them via a manual workflow dispatch in the actions tab.
assignUser commentedon May 12, 2025
Hm, I think we could solve this within
pull_requestas a trigger by gating 'extended' jobs on the commit title. So you could just push an empty commit with[run extended]or something to kick them off. That way all the potential security issues go away.kou commentedon May 20, 2025
How about using
CI: Extralabel to run extra CI jobs?#46501 is an implementation.
assignUser commentedon May 21, 2025
Yes, that seems a bit nicer and still doesn't require a new privileged job! Great!
kou commentedon May 22, 2025
Let's start this with the label approach.
GH-46499: [CI][Crossbow][C++] Use apache/arrow for Meson (#46501)
14 remaining items
kou commentedon Sep 16, 2025
How about
strategy.fail-fast: ${{ github.event_name == 'pull_request' }}?We don't use
fail-fastonly on pull request. Developers can see all results on their fork repository.I don't like this approach. It doesn't solve the problems in the description.
pitrou commentedon Sep 16, 2025
Ok, perhaps it's possible to have GH workflows that are triggered by a specific
@github-actionscomment? So that we can still select jobs with a fine granularity?raulcd commentedon Sep 16, 2025
We could trigger workflows via comment, those won't report on the comment section but as action checks getting rid of the majority of the clutter problem on PRs.
Using a mix of listen comments actions and gh workflow with some parameters. I am thinking on triggering something like this:
gh workflow run cpp-extra.yml -f job_pattern=meson-*And with some pattern matching checks on the workflows we could skip certain jobs.
raulcd commentedon Sep 16, 2025
I did a small test and
gh workflow runeven when using the valid ref/branch doesn't report on the checks section of the PR which makes the approach quite useless. Other things I found, it would require permissionsactions: writeon the bot comment action to trigger the workflow and we would requireworkflow_dispatchon the workflows to be able to be triggered by the bot. The action I was testing looked like this:72b0346...raulcd:arrow:test-comment-bot
An example of the workflow triggered:
https://github.com/raulcd/arrow/actions/runs/17770172354
And the PR without any reference to that workflow:
raulcd#96
kou commentedon Sep 17, 2025
Hmm. I think that this is enough for us...
In general, the
git push-> post a@github-actions ...comment to run jobs -> check results ->git push-> post a@github-actions ...comment to run jobs -> check results workflow is inconvenient than thegit push-> check results ->git push-> check results workflow for me. It has one more step (post a comment) and increases needless comment history. So I don't want to use the workflow as much as possible.If we really want to filter jobs, how about adding more
CI: Extra: ...labels?pitrou commentedon Feb 3, 2026
Some further suggestions for extra additions:
kou commentedon Feb 4, 2026
+1 but we can't use
pull_request_targetfor "post a comment with the preview URL"... See also: apache/arrow-dotnet#255pitrou commentedon Feb 4, 2026
Does that mean it's not possible to post a comment at all?
pitrou commentedon Feb 4, 2026
(sorry for closing, I hit the wrong button)
kou commentedon Feb 5, 2026
We can use
on.scheduleinstead ofon.pull_request_targetfor it but theon.scheduleapproach uses polling style instead of on demand style.pitrou commentedon Feb 5, 2026
Gosh. Can we perhaps discuss with the ASF if the
pull_request_targetban can be made more selective?kou commentedon Feb 6, 2026
It's a good idea. I think that
pull_request_targetwithoutactions/checkoutshould be acceptable.