Open miry opened 7 months ago
I had wondered about this as well. However, so far only members have worked on the building setup so this wasn't an issue. Having an easy path for external contributors would certainly be nice, but it should also be put in perspective. We should not waste a considerable amount of effort to set this up if it's barely used afterwards.
It works - though not as smooth - to have someone with push rights assist external contributors. Or we could give the necessary access rights to trusted contributors so they can work on their own.
Anyway, some notes on the topic:
distribution-scripts
require a commit on crystal
to test them. This could perhaps be automated, but maybe changing the basic setup would make this easier. For example we could swap the relationship between repos, having CI defined in distribution-scripts
and pull in the content from crystal
(instead of the other way around). This would make it easier to contribute to distribution-scripts
. It would still be triggered from releases on crystal
(but also other triggers internal to distribution-scripts
).@straight-shoota thank you for the clarification
TLDR: I have built prototype and would require few tweaks in both repos (https://github.com/crystal-lang/distribution-scripts/pull/273) and (https://github.com/crystal-lang/crystal/compare/master...miry:crystal:test-darwin). It is still require a script to trigger job and docs how to start testing.
It looks like this: CircleCI workflow
Because all circle ci runners would be run on behalf of Contributors, it would garantie that secrets from crystal org are not shared or leaked. I see also plus compute resources would be distributed among users.
It would be much better. I think it is anyway done partialy on circleci config for builds like darwin and linux - I found in scripts downloading of full crystal repo. UPDATE: I am still think #273 would be good for this scenario as well.
Let me know if you ok with my prototype or I should check second posobility instead.
Because all circle ci runners would be run on behalf of Contributors, it would garantie that secrets from crystal org are not shared or leaked.
I suppose we would want CI to run on PRs (i.e. in crystal-org), though. Not just on contributor's branches. But I expect we could manage to keep secrets limited to the release environment.
Moving release CI here seems like a good idea. It's probably gonna take some time, though.
But we can simply start by setting up the CI workflows in this repo. Doesn't need to be the full thing and it can grow gradually. Once we know it works, we can swap release builds in.
Another important aspect though is that we've had the idea to migrate the release workflow to GitHub Actions. The main reason for this being aarch64-linux builds on our own runners (tests are already running there). The CircleCI OpenSource plan doesn't seem to allow custom runners, unfortunately.
There has already been some progress on this in #211, but I'm not sure where exactly we're standing with that. That PR is definitely quite huge and contains lots of individual changes. We can probably take a lot of things from there, though.
Introduced 2 PRs to migrate some CI functionalities from CircleCI to GithubActions:
Currently it is required core developers, who has access to crystal-lang/crystal to run tests and dist jobs. It is not effective with more contributors.
circleci allows to trigger pipelines with custom paramaters. Example:
sample circleci workflow![image](https://github.com/crystal-lang/distribution-scripts/assets/21104/e7e8f322-0f7b-4f88-91ab-43c93707b775)
TODO:
References