Skip to content

Conversation

hebasto
Copy link
Member

@hebasto hebasto commented Jul 30, 2023

From #28098:

Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.

If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.


IMPORTANT NOTE. We currently ship macOS release binaries for both architectures: x86_64 and arm64. If this PR gets merged, only x86_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 to arm64 in #26388 less than a year ago.


Security concerns:

GITHUB_TOKEN permissions (from the build log in my personal repo):

2023-07-27T07:30:17.8313534Z ##[group]GITHUB_TOKEN Permissions
2023-07-27T07:30:17.8314113Z Contents: read
2023-07-27T07:30:17.8314608Z Metadata: read
2023-07-27T07:30:17.8314957Z Packages: read
2023-07-27T07:30:17.8315233Z ##[endgroup]

Comparison of resources:

Resource Current, Cirrus CI Suggested, GitHub Actions
CPU 4 4 **
RAM, GB 8 14

** NOTE: However, docs are mentioning:

3-core CPU (x86_64)

@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 30, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK MarcoFalke, jarolrod, achow101

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #28173 (ci: Run Windows native task on GitHub Actions by hebasto)
  • #21652 (ci: Switch more tasks to self-hosted by MarcoFalke)

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.

@fanquake
Copy link
Member

This is replacing the arm64 job with an x86_64 job?

@hebasto
Copy link
Member Author

hebasto commented Jul 30, 2023

This is replacing the arm64 job with an x86_64 job?

Yes. No arm64 macOS images are available in GitHub Actions for now.

@fanquake
Copy link
Member

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.

@hebasto
Copy link
Member Author

hebasto commented Jul 30, 2023

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.

@maflcko
Copy link
Member

maflcko commented Jul 31, 2023

Can you link to 10 passing tests in your fork? Otherwise we may run into intermittent issues.

Copy link
Member

@maflcko maflcko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, Should squash?

@fanquake
Copy link
Member

~0 Is there any reason we can't use the public beta of the arm64 runners? Have we tested that at-least?

Copy link
Member

@maflcko maflcko left a 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.

@fanquake
Copy link
Member

Can you add a link to documentation on how to set that up?

Trying to find that at the moment. Maybe it doesn't exist.

unless you can point to a bug that was found with arm64, but not with amd64.

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.

@maflcko
Copy link
Member

maflcko commented Jul 31, 2023

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.

@maflcko
Copy link
Member

maflcko commented Aug 4, 2023

All other comments are to be addressed shortly.

Are you still working on this? Apart from a squash and addressing the 4 review comments this is rfm, no?

@hebasto
Copy link
Member Author

hebasto commented Aug 4, 2023

All other comments are to be addressed shortly.

Are you still working on this?

I am. My apologies for a delay.

@hebasto
Copy link
Member Author

hebasto commented Aug 4, 2023

From IRC:

14:22 <fanquake> Yea the PR description in that PR needs updating to actually explain what’s its doing (dropping support for a release platform from CI), rather than making it look like just swapping infra

The PR description has been updated.

Copy link
Member

@maflcko maflcko left a 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==

@maflcko
Copy link
Member

maflcko commented Aug 4, 2023

re-ACK fe34609 🐺

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: re-ACK fe34609476b11cdd907c298f7300d424bf556e98  🐺
5foeQdRIfx+XD3h5NuqyHHxTffqWN12HFWwYwYPPXiL9DHdTWEyvDuMH8wTC9SuQbCRhrqLCBC4F3+kGDwKKAw==

@maflcko maflcko added this to the 26.0 milestone Aug 4, 2023

env:
DANGER_RUN_CI_ON_HOST: 1
TEST_RUNNER_TIMEOUT_FACTOR: 40
Copy link
Member

@maflcko maflcko Aug 15, 2023

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

Copy link
Member

@maflcko maflcko Aug 15, 2023

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:
Copy link
Member

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in #28278

@achow101
Copy link
Member

ACK 9658d0d

@DrahtBot DrahtBot removed the request for review from achow101 August 15, 2023 21:03
@achow101 achow101 merged commit b97b050 into bitcoin:master Aug 15, 2023
env:
MAKEJOBS: '-j4'
CI_USE_APT_INSTALL: 'no'
PACKAGE_MANAGER_INSTALL: 'echo' # Nothing to do
Copy link
Member

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?

Copy link
Member

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'
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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'
Copy link
Member

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?

Copy link
Member

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
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

@hebasto hebasto Aug 16, 2023

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member Author

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.

@maflcko
Copy link
Member

maflcko commented Aug 17, 2023

Looks like it is now even harder to re-run tasks, if there is an intermittent network issue (for example if GH or GHA is down, which happens ~daily).

At least, all I can do is download the log, whereas on Cirrus, I can re-run my own pull.

Screen Shot 2023-08-17 at 11 54 48

@fanquake
Copy link
Member

Looks like it is now even harder to re-run tasks,

So there is no way for developers to re-run there own PRs at all, with GitHub Actions? Other than I assume force pushing?

@hebasto
Copy link
Member Author

hebasto commented Aug 17, 2023

Looks like it is now even harder to re-run tasks,

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.

@maflcko
Copy link
Member

maflcko commented Aug 17, 2023

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?

@fanquake
Copy link
Member

fanquake commented Aug 17, 2023

That page says "People with write permissions to a repository can re-run workflows in the repository."

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.

can confirm whether they can re-run on Cirrus?

Contributors can definitely re-run Cirrus jobs. Looks like they cannot re-run Github Actions workflows.

@dergoegge
Copy link
Member

Maybe someone else without write access can confirm whether they can re-run on Cirrus?

I can't re-run GH actions tasks but am able to re-run cirrus jobs.

@hebasto
Copy link
Member Author

hebasto commented Aug 17, 2023

Maybe someone else without write access can confirm whether they can re-run on Cirrus?

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?

@dergoegge
Copy link
Member

Does closing a PR and following re-opening it work?

No, that just cancels all jobs and the gha one just continues running

@maflcko
Copy link
Member

maflcko commented Aug 17, 2023

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

fanquake added a commit to bitcoin-core/gui that referenced this pull request Aug 17, 2023
…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
@hebasto
Copy link
Member Author

hebasto commented Aug 17, 2023

Also, it looks like CI tasks currently need approval from a maintainer to run at all from non-members. See docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

It is a configurable setting.

@achow101
Copy link
Member

Also, it looks like CI tasks currently need approval from a maintainer to run at all from non-members. See docs.github.com/en/actions/managing-workflow-runs/approving-workflow-runs-from-public-forks

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.

sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Aug 17, 2023
… `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
fanquake added a commit to bitcoin-core/gui that referenced this pull request Aug 21, 2023
… 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
Frank-GER pushed a commit to syscoin/syscoin that referenced this pull request Sep 8, 2023
…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
@bitcoin bitcoin locked and limited conversation to collaborators Aug 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants