Skip to content
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

github/workflows: add ARM macos build binaries job #6427

Merged
merged 33 commits into from
Nov 21, 2024

Conversation

iulianbarbu
Copy link
Contributor

@iulianbarbu iulianbarbu commented Nov 10, 2024

Description

This PR adds the required changes to release polkadot, polkadot-parachain and polkadot-omni-node binaries built on Apple Sillicon macos.

Integration

This addresses requests from the community for such binaries: #802, and they should be part of the Github release page.

Review Notes

Test on paritytech-stg solely focused on macos binaries: https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308, except the steps related to pgpkms (which need AWS credentials, missing from paritytech-stg). The binary names don't have a darwin-arm identifier, and conflict with the existing x86_64-linux binaries. I haven't tested building everything on paritytech-stg because the x86_64-linux builds run on unbutu-latest-m which isn't enabled on pairtytech-stg (and I haven't asked CI team to enable one), so testing how to go around naming conflicts should be covered next.

TODO

  • Test the workflow start to end (especially the last bits related to uploading the binaries on S3 and ensuring the previous binaries and the new ones coexist harmoniously on S3/action artifacts storage without naming conflicts) @EgorPopelyaev
  • Publish the arm binaries on the Github release page - to clarify what's needed @iulianbarbu . Current practice is to manually publish the binaries built via release-build-rc.yml workflow, taken from S3. Would be great to have the binaries there in the first place before working on automating this, but I would also do it in a follow up PR.

Follow ups

  • unify the binaries building under release-30_publish_release_draft.yml maybe?
  • automate binary artifacts upload to S3 in release-30_publish_release_draft.yml

Signed-off-by: Iulian Barbu <[email protected]>
@iulianbarbu iulianbarbu self-assigned this Nov 10, 2024
@iulianbarbu iulianbarbu added the R0-silent Changes should not be mentioned in any release notes label Nov 10, 2024
@iulianbarbu iulianbarbu marked this pull request as ready for review November 10, 2024 16:01
@iulianbarbu iulianbarbu requested review from a team as code owners November 10, 2024 16:01
@iulianbarbu iulianbarbu marked this pull request as draft November 10, 2024 16:01
Signed-off-by: Iulian Barbu <[email protected]>
Signed-off-by: Iulian Barbu <[email protected]>
@iulianbarbu iulianbarbu changed the title github/workflows: add macos build binaries job github/workflows: add ARM macos build binaries job Nov 14, 2024
@iulianbarbu
Copy link
Contributor Author

@EgorPopelyaev can you take a look at this PR from a testing point of view when you have some time? (the part I tagged you for in the PR description). I can't test the action in terms of binaries S3 upload, and around the naming conflict aspects.

.github/scripts/release/build-macos-release.sh Outdated Show resolved Hide resolved
.github/scripts/release/release_lib.sh Outdated Show resolved Hide resolved
.github/workflows/release-build-rc.yml Outdated Show resolved Hide resolved
@iulianbarbu iulianbarbu added this pull request to the merge queue Nov 21, 2024
Merged via the queue into master with commit 1f7765b Nov 21, 2024
195 of 199 checks passed
@iulianbarbu iulianbarbu deleted the ib-enable-arm-binaries branch November 21, 2024 15:51
@EgorPopelyaev EgorPopelyaev added the A4-needs-backport Pull request must be backported to all maintained releases. label Nov 21, 2024
@paritytech-cmd-bot-polkadot-sdk

Created backport PR for stable2407:

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-6427-to-stable2407
git worktree add --checkout .worktree/backport-6427-to-stable2407 backport-6427-to-stable2407
cd .worktree/backport-6427-to-stable2407
git reset --hard HEAD^
git cherry-pick -x 1f7765b63530e362d6b1b4a225b47daddda03637
git push --force-with-lease

@paritytech-cmd-bot-polkadot-sdk

Created backport PR for stable2409:

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin backport-6427-to-stable2409
git worktree add --checkout .worktree/backport-6427-to-stable2409 backport-6427-to-stable2409
cd .worktree/backport-6427-to-stable2409
git reset --hard HEAD^
git cherry-pick -x 1f7765b63530e362d6b1b4a225b47daddda03637
git push --force-with-lease

EgorPopelyaev added a commit that referenced this pull request Nov 21, 2024
# Description

This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

## Integration

This addresses requests from the community for such binaries: #802, and
they should be part of the Github release page.

## Review Notes

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

### TODO

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

### Follow ups

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

---------

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: EgorPopelyaev <[email protected]>
iulianbarbu added a commit that referenced this pull request Nov 22, 2024
This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

This addresses requests from the community for such binaries: #802, and
they should be part of the Github release page.

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

---------

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: EgorPopelyaev <[email protected]>
iulianbarbu added a commit that referenced this pull request Nov 22, 2024
This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

This addresses requests from the community for such binaries: #802, and
they should be part of the Github release page.

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

---------

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: EgorPopelyaev <[email protected]>
EgorPopelyaev added a commit that referenced this pull request Nov 25, 2024
… job (#6427) (#6596)

# Description

This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

## Integration

This addresses requests from the community for such binaries: #802, and
they should be part of the Github release page.

## Review Notes

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

### TODO

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

### Follow ups

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: Iulian Barbu <[email protected]>
Krayt78 pushed a commit to Krayt78/polkadot-sdk that referenced this pull request Dec 18, 2024
# Description

This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

## Integration

This addresses requests from the community for such binaries: paritytech#802, and
they should be part of the Github release page.

## Review Notes

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

### TODO

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

### Follow ups

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

---------

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: EgorPopelyaev <[email protected]>
dudo50 pushed a commit to paraspell-research/polkadot-sdk that referenced this pull request Jan 4, 2025
# Description

This PR adds the required changes to release `polkadot`,
`polkadot-parachain` and `polkadot-omni-node` binaries built on Apple
Sillicon macos.

## Integration

This addresses requests from the community for such binaries: paritytech#802, and
they should be part of the Github release page.

## Review Notes

Test on paritytech-stg solely focused on macos binaries:
https://github.com/paritytech-stg/polkadot-sdk/actions/runs/11824692766/job/32946793308,
except the steps related to `pgpkms` (which need AWS credentials,
missing from paritytech-stg). The binary names don't have a `darwin-arm`
identifier, and conflict with the existing x86_64-linux binaries. I
haven't tested building everything on `paritytech-stg` because the
x86_64-linux builds run on `unbutu-latest-m` which isn't enabled on
`pairtytech-stg` (and I haven't asked CI team to enable one), so testing
how to go around naming conflicts should be covered next.

### TODO

- [x] Test the workflow start to end (especially the last bits related
to uploading the binaries on S3 and ensuring the previous binaries and
the new ones coexist harmoniously on S3/action artifacts storage without
naming conflicts) @EgorPopelyaev
- [x] Publish the arm binaries on the Github release page - to clarify
what's needed @iulianbarbu . Current practice is to manually publish the
binaries built via `release-build-rc.yml` workflow, taken from S3. Would
be great to have the binaries there in the first place before working on
automating this, but I would also do it in a follow up PR.

### Follow ups

- [ ] unify the binaries building under
`release-30_publish_release_draft.yml` maybe?
- [ ] automate binary artifacts upload to S3 in
`release-30_publish_release_draft.yml`

---------

Signed-off-by: Iulian Barbu <[email protected]>
Co-authored-by: EgorPopelyaev <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A4-needs-backport Pull request must be backported to all maintained releases. R0-silent Changes should not be mentioned in any release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants