-
Notifications
You must be signed in to change notification settings - Fork 37.8k
ci: Run "macOS native x86_64" job on GitHub Actions #28187
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
This is replacing the arm64 job with an x86_64 job? |
Yes. No |
The PR description should probably mention that, as it's a regression in terms of testing. i.e no-longer testing on Apples primarily supported hardware. |
Done. |
Can you link to 10 passing tests in your fork? Otherwise we may run into intermittent issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, Should squash?
~0 Is there any reason we can't use the public beta of the arm64 runners? Have we tested that at-least? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
~0 Is there any reason we can't use the public beta of the arm64 runners? Have we tested that at-least?
Can you add a link to documentation on how to set that up? With details on the runners, etc. In any case, I don't think it matters, unless you can point to a bug that was found with arm64, but not with amd64. In practice, I expect all bugs found by CI to be found by both macOS arches.
Trying to find that at the moment. Maybe it doesn't exist.
I think it's at least worth bringing up, as the PR as presented, didn't mention that it drops (direct) testing of one of our release platforms entirely, and presented this change as-if just swapping underlying CI provider. In terms of differences, there are code paths that are currently exercised in our CI, that no-longer would be after this change, i.e use of macOS ARM intrinsics, so we may be less-likely to detect any breakage if related code is changed, i.e can't sanity check in the CI that detection is working. Maybe that doesn't matter, I do agree that most bugs should be found in either case. |
yeah, it should be a trivial two line diff to switch to arm, once and if GitHub supports it. Seems fine to use intel for now, if the alternative is no macOS CI at all. |
Are you still working on this? Apart from a squash and addressing the 4 review comments this is rfm, no? |
I am. My apologies for a delay. |
Updated e9b7218 -> cc26f0d (pr28187.03 -> pr28187.04):
|
From IRC:
The PR description has been updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm ACK cc26f0d 🖐
Show signature
Signature:
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: lgtm ACK cc26f0d8c8539094db8d95da9fa46ea1247a0d8c 🖐
hvJ/DOYbi+VSxM5yYqoUvgK/U86A7rpQTGv2wNi1lLHZOushQXVRrU9nznuLgMptqRzWzBwp4zMzw3g0Vz/1Aw==
re-ACK fe34609 🐺 Show signatureSignature:
|
|
||
env: | ||
DANGER_RUN_CI_ON_HOST: 1 | ||
TEST_RUNNER_TIMEOUT_FACTOR: 40 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot CI_FAILFAST_TEST_LEAVE_DANGLING
? Otherwise, it would be good to see a functional test failure log
Edit: Done in #28278
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, CCACHE_NOHASHDIR
? Or maybe that'd be better moved to ./ci/test/00_setup_env.sh
Edit: Not yet done.
TEST_RUNNER_TIMEOUT_FACTOR: 40 | ||
|
||
jobs: | ||
macos-native-x86_64: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe add a comment linking to github/roadmap#528 to say that this should be used, when available?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done in #28278
ACK 9658d0d |
env: | ||
MAKEJOBS: '-j4' | ||
CI_USE_APT_INSTALL: 'no' | ||
PACKAGE_MANAGER_INSTALL: 'echo' # Nothing to do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think this can be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in #28278
|
||
env: | ||
MAKEJOBS: '-j4' | ||
CI_USE_APT_INSTALL: 'no' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated: Maybe remove this and replace it with a check on CI_OS_NAME?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in #28278
# No need to run on the read-only mirror, unless it is a PR. | ||
if: github.repository != 'bitcoin-core/gui' || github.event_name == 'pull_request' | ||
|
||
timeout-minutes: 120 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also abort on a force push, to avoid wasting CPU, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GHActions have no such a feature by default. It should be a separated workflow that processes pull_request.synchronize
event and terminates other workflows. However, I'm not sure about the exact implementation for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So if someone (honestly) pushes to a pull request a few times in a few minutes, it will block CI progress on all other pulls, assuming a few more tasks are run on GHA and the "free" limit is reached?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should also abort on a force push, to avoid wasting CPU, no?
Done in #28282.
timeout-minutes: 120 | ||
|
||
env: | ||
MAKEJOBS: '-j4' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to reduce this to 4 when it previously was 10?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed in #28278
with: | ||
path: ${{ env.CCACHE_DIR }} | ||
key: ${{ github.job }}-ccache-cache-${{ github.run_id }} | ||
restore-keys: ${{ github.job }}-ccache-cache |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like each pull request will rewrite the ccache and thus the hit rate will be ~0% overall?
Would be better to get the cache from the own pull only, or master.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, looks like caching doesn't work at all here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, looks like caching doesn't work at all here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't work, why was any of this added to the CI template?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it works when there are no pull requests. It should be possible to fix this in a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it doesn't work, why was any of this added to the CI template?
Ccache regression, introduced in #19683, should be fixed. It is not related to the CI template that is correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this related. This is the "macOS native", not "macOS-cross" task.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How is this related. This is the "macOS native", not "macOS-cross" task.
My bad. Sorry for the noise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, looks like caching doesn't work at all here?
It works.
I think it works when there are no pull requests. It should be possible to fix this in a follow-up.
Yes, pull requests should not create their own caches. Going to address this issue shortly.
So there is no way for developers to re-run there own PRs at all, with GitHub Actions? Other than I assume force pushing? |
Docs are not super clear about that: https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs. |
That page says "People with write permissions to a repository can re-run workflows in the repository." Maybe someone else without write access can confirm whether they can re-run on Cirrus? |
Hopefully not. If this really is the case, that's another downside to GH Actions, and going to be a worse developer experience (we can't give write access to all contributors just to re-run CI). Would have been good if these things had been explained in the PR description, or discussion.
Contributors can definitely re-run Cirrus jobs. Looks like they cannot re-run Github Actions workflows. |
I can't re-run GH actions tasks but am able to re-run cirrus jobs. |
Does closing a PR and following re-opening it work? |
No, that just cancels all jobs and the gha one just continues running |
Also, it looks like CI tasks currently need approval from a maintainer to run at all from non-members. See https://docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks |
…rocesses `github.ref` at a time 0080b56 ci: Ensure that only a single workflow processes `github.ref` at a time (Hennadii Stepanov) Pull request description: This PR ensures that only a single workflow processes any push or pull request at a time. A new push will be queued (including the master branch). For a new pull request update, the previous in-progress one will be cancelled. Address bitcoin/bitcoin#28187 (comment). ACKs for top commit: dergoegge: utACK 0080b56 Tree-SHA512: d03f1678c93c817c1c3be5e75171bfe85d494f99a9aab7113c9438e0c820e950edd5c10199cccd54868e6dc50217bb3aa5601b23bc88ad4927c001031e917513
It is a configurable setting. |
It's currently set to "Require approval for first-time contributors". Could change that to "Require approval for first-time contributors who are new to GitHub". There's no "off" option. |
… `github.ref` at a time 0080b56 ci: Ensure that only a single workflow processes `github.ref` at a time (Hennadii Stepanov) Pull request description: This PR ensures that only a single workflow processes any push or pull request at a time. A new push will be queued (including the master branch). For a new pull request update, the previous in-progress one will be cancelled. Address bitcoin#28187 (comment). ACKs for top commit: dergoegge: utACK 0080b56 Tree-SHA512: d03f1678c93c817c1c3be5e75171bfe85d494f99a9aab7113c9438e0c820e950edd5c10199cccd54868e6dc50217bb3aa5601b23bc88ad4927c001031e917513
… in GitHub Actions 241d6ca ci: Disable cache save for pull requests in GitHub Actions (Hennadii Stepanov) Pull request description: This PR disable cache save for pull requests in GitHub Actions. Otherwise, multiple pull requests fill GitHub Actions cache quota shortly. See a discussion [here](bitcoin/bitcoin#28187 (comment)). --- **NOTE** for the maintainers with "owner" permissions. This PR needs the `actions/cache/restore@*` and `actions/cache/save@*` acrions to be explicitly allowed in the repository's Actions permissions. ACKs for top commit: MarcoFalke: lgtm ACK 241d6ca Tree-SHA512: a7786c7ec99bfa6991bf6ae08fd7ed3546e8c5d083a1b2bae7638f6f31e77fdf2cf4fc69d85834faf87f98db1f4a82026ce1dc5fc1bc6650e8bf1c09bf7e90f5
…ub Actions 241d6ca ci: Disable cache save for pull requests in GitHub Actions (Hennadii Stepanov) Pull request description: This PR disable cache save for pull requests in GitHub Actions. Otherwise, multiple pull requests fill GitHub Actions cache quota shortly. See a discussion [here](bitcoin#28187 (comment)). --- **NOTE** for the maintainers with "owner" permissions. This PR needs the `actions/cache/restore@*` and `actions/cache/save@*` acrions to be explicitly allowed in the repository's Actions permissions. ACKs for top commit: MarcoFalke: lgtm ACK 241d6ca Tree-SHA512: a7786c7ec99bfa6991bf6ae08fd7ed3546e8c5d083a1b2bae7638f6f31e77fdf2cf4fc69d85834faf87f98db1f4a82026ce1dc5fc1bc6650e8bf1c09bf7e90f5
From #28098:
IMPORTANT NOTE. We currently ship macOS release binaries for both architectures:
x86_64
andarm64
. If this PR gets merged, onlyx86_64
architecture will be tested on CI, which implies some drawbacks.However, it has never been the case that our CI tested both architectures simultaneously. And we hope that GitHub Actions will soon host macOS
arm64
runners.Historically, we moved from
x86_64
toarm64
in #26388 less than a year ago.Security concerns:
GITHUB_TOKEN
permissions (from the build log in my personal repo):Comparison of resources:
** NOTE: However, docs are mentioning: