-
Notifications
You must be signed in to change notification settings - Fork 564
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 Actions: Build Arch Live ISO With Each Commit Included #275
Conversation
The bind mount is probably not necessary
0bbbc0f
to
92b8143
Compare
f62ca95
to
0762a71
Compare
Just a ridiculous question before I merge.. Or two..
|
So, for #1 I'm not sure but they don't seem to prevent it. It's automatically deleted after 90 days by default |
It looks like on the project level we can change this to 7 days or so? Might make it so we're not 'abusing' GitHub's storage too much. It's a setting and not something you commit. |
This wording seems to indicate they're perfectly fine with it: About billing for GitHub Actions As a legitimate public open-source project I think we'll be okay. |
As long as we're not racking up a quota for Arch Linux public account some how, I'd be fine with this. |
Migration is actually really easy for this; I have a ton of experience with GitLab runners from working with them professionally at work and could make a .gitlab-ci.yaml file for this in very little time. :) We just need a worker node hosted somewhere with a privileged Docker runner (to allow for it to build). We'd put the tags on the build job for that so it picks up the correct runner and convert the runs to an inline script. |
I think should be triggered only on master or when new PR's are submitted, not on each and every commit. |
You are probably right but I do not know if that will retrigger the pipeline if you amend a pull request with additional commits. Also, since GitHub doesn't give us a quota for builds as a free and open source project, having more builds than we need may not be an issue. |
I've seen it being done on other projects, so I think it's possible. |
Let me do a quick test. I will make a new commit to this pull request and change it so it just runs on pull requests and see if it runs with the additional commit. |
Okay so it looks like that works. I'm fine with changing it, and it's probably okay to go in now. It's not like this can possibly break the library itself. |
Instead of closing and re-opening, I wouldn't mind the PR being marked as WIP, helps out with knowing what's being worked on and what's tested and done. But it looks good with |
Didn't mean to close and re-open, these buttons are too close together to try to reply on mobile and it doesn't offer confirmation. :( |
I did just realize something tho, and that is: Does every PR trigger this before being merged? Wouldn't that mean if I spawn two PR's, the last one will overwrite the ISO? I guess this isn't an issue, but a bit weird for testing purposes. Not knowing which ISO i get. |
It's not an overwrite. Each has it's OWN iso file :) |
Awesome! Again, this is some what of black magic to me. |
So this is a really neat CI/CD feature I'm testing out - we can have GitHub automatically build us ISOs to test to avoid having to replace ArchInstall on a vanilla Arch image. I want to get it to automatically launch as well - I think this will prove to be incredibly useful when done.
This will enable the following workflow when reviewing a change/pull request: