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 Actions: Build Arch Live ISO With Each Commit Included #275

Merged
merged 4 commits into from
Apr 11, 2021

Conversation

dylanmtaylor
Copy link
Contributor

@dylanmtaylor dylanmtaylor commented Apr 10, 2021

Screenshot from 2021-04-10 17-49-08

VirtualBox_arch_10_04_2021_20_02_01

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:

  • Download ISO
  • Start up VM or Write to USB
  • The specific ArchInstall commit will be automatically installed and you can run it with python -m archinstall

@dylanmtaylor dylanmtaylor requested a review from Torxed as a code owner April 10, 2021 20:14

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.
The bind mount is probably not necessary
@dylanmtaylor dylanmtaylor force-pushed the continuous-integration branch from 0bbbc0f to 92b8143 Compare April 10, 2021 21:32
@dylanmtaylor dylanmtaylor changed the title GitLab Actions (WIP): Build Arch Live ISO with Each Commit GitLab Actions: Build Arch Live ISO With Each Commit Included Apr 10, 2021
@dylanmtaylor dylanmtaylor force-pushed the continuous-integration branch from f62ca95 to 0762a71 Compare April 10, 2021 22:00
@Torxed
Copy link
Member

Torxed commented Apr 11, 2021

Just a ridiculous question before I merge.. Or two..

  1. Is this allowed? Are we allowed to store 700+ MB worth of binary stuff on Github actions? @grazzolini?
  2. Would every commit triggers this and would it remove the old ISO? Just making sure we're cleaning up after us.

@dylanmtaylor
Copy link
Contributor Author

Just a ridiculous question before I merge.. Or two..

  1. Is this allowed? Are we allowed to store 700+ MB worth of binary stuff on Github actions? @grazzolini?
  2. Would every commit triggers this and would it remove the old ISO? Just making sure we're cleaning up after us.

So, for #1 I'm not sure but they don't seem to prevent it. It's automatically deleted after 90 days by default

@dylanmtaylor
Copy link
Contributor Author

dylanmtaylor commented Apr 11, 2021

Just a ridiculous question before I merge.. Or two..

  1. Is this allowed? Are we allowed to store 700+ MB worth of binary stuff on Github actions? @grazzolini?
  2. Would every commit triggers this and would it remove the old ISO? Just making sure we're cleaning up after us.

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.

@dylanmtaylor
Copy link
Contributor Author

This wording seems to indicate they're perfectly fine with it:

About billing for GitHub Actions
GitHub Actions usage is free for both public repositories and self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits

As a legitimate public open-source project I think we'll be okay.

@Torxed
Copy link
Member

Torxed commented Apr 11, 2021

This wording seems to indicate they're perfectly fine with it:

About billing for GitHub Actions
GitHub Actions usage is free for both public repositories and self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits

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.
Just a note here that this project will eventually make it's way into the official GitLab when that opens up for the public, in which case we'll need to re-visit this and migrate it.

@dylanmtaylor
Copy link
Contributor Author

dylanmtaylor commented Apr 11, 2021

This wording seems to indicate they're perfectly fine with it:
About billing for GitHub Actions
GitHub Actions usage is free for both public repositories and self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits
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.
Just a note here that this project will eventually make it's way into the official GitLab when that opens up for the public, in which case we'll need to re-visit this and migrate it.

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.

@dylanmtaylor dylanmtaylor changed the title GitLab Actions: Build Arch Live ISO With Each Commit Included GitHub Actions: Build Arch Live ISO With Each Commit Included Apr 11, 2021
@grazzolini
Copy link
Member

I think should be triggered only on master or when new PR's are submitted, not on each and every commit.

@dylanmtaylor
Copy link
Contributor Author

dylanmtaylor commented Apr 11, 2021

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.

@grazzolini
Copy link
Member

I've seen it being done on other projects, so I think it's possible.

@dylanmtaylor
Copy link
Contributor Author

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.

@dylanmtaylor
Copy link
Contributor Author

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.

@Torxed
Copy link
Member

Torxed commented Apr 11, 2021

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 pull_request so I'm merging :) Consider this the first official test of the runner hehe.

@dylanmtaylor
Copy link
Contributor Author

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 pull_request so I'm merging :) Consider this the first official test of the runner hehe.

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. :(

@Torxed
Copy link
Member

Torxed commented Apr 11, 2021

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.

@Torxed Torxed merged commit 6f08ad1 into archlinux:master Apr 11, 2021
@dylanmtaylor
Copy link
Contributor Author

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 :)

@dylanmtaylor dylanmtaylor deleted the continuous-integration branch April 11, 2021 19:57
@Torxed
Copy link
Member

Torxed commented Apr 11, 2021

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.
But that is great to hear, and I'm glad it's not on each commit heh.

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.

None yet

3 participants