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

Build all Erlang versions and upload to PackageCloud #6

Merged
merged 29 commits into from
Apr 12, 2024

Conversation

carlhoerberg
Copy link
Member

In a script, run by GH Actions.

@dentarg
Copy link
Member

dentarg commented Apr 11, 2024

An alternative approach could be like we have done over at cloudamqp/rabbitmq-erlang where we have a workflow that can build a single version (in that case there, it is a version combo) and then we trigger multiple builds of that workflow. That would avoid long running builds, and make it more clear what version a certain build built, and easy to re-run individual builds.

@carlhoerberg
Copy link
Member Author

Yes, was thinking of that too but couldn't figure out a good way to trigger new jobs, only repository_dispatch. Depot.dev is also pretty fast and supports native arm64 builds.

@dentarg
Copy link
Member

dentarg commented Apr 11, 2024

It would all live inside this repo so workflow_dispatch ought to work and the CLI could be used: https://cli.github.com/manual/gh_workflow_run (we would need to add a GitHub access token to the secrets, can't start new workflows with the default token). We could still make use of depot.dev.

@carlhoerberg
Copy link
Member Author

ok! can continue tmrw

@carlhoerberg
Copy link
Member Author

one workflow dispatch per image/erlang_version/platform? downside with that is that we will trigger a lot of workflows. alterantive is to use a matrix, so a single workflow but many jobs, but don't get how you can pass a hash to workflow_dispatch which then can be used as a matrix: include, if it was just an array i guess it would work. Maybe that's a comprimise, that you can only specify a version, and then we build that version for all platforms and images regardless? Another upside of that is that we can limit the concurrency of the matrix/jobs.

@carlhoerberg
Copy link
Member Author

can't limit the number of concurrent workflows afaik, and then we can run into issues with depot.dev..

@dentarg
Copy link
Member

dentarg commented Apr 12, 2024

@carlhoerberg
Copy link
Member Author

Ok, thanks!

@carlhoerberg
Copy link
Member Author

Used a multi step workflow instead, and fromJson.

@carlhoerberg carlhoerberg merged commit 4b0d107 into main Apr 12, 2024
5 of 154 checks passed
@carlhoerberg carlhoerberg deleted the build-all-and-upload branch April 12, 2024 21:29
@carlhoerberg carlhoerberg mentioned this pull request Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants