-
Notifications
You must be signed in to change notification settings - Fork 760
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
[stable2409] Backport #6427 #6594
base: stable2409
Are you sure you want to change the base?
[stable2409] Backport #6427 #6594
Conversation
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 |
This pull request is amending an existing release. Please proceed with extreme caution,
Emergency Bypass
If you really need to bypass this check: add |
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]>
Signed-off-by: Iulian Barbu <[email protected]>
35384f0
to
261d58d
Compare
Will leave here a note: @EgorPopelyaev , since for stable2409 we don't have these action and they are completely new files, might be worth testing them before merging. Will leave this PR in draft mode until the testing concludes. |
Backport #6427 into
stable2409
from iulianbarbu.See the documentation on how to use this bot.