Hi, I'd like to either request access to some powerful amd64 hardware, or a new instance to go through our Github pull requests. I'm currently using laptop most of the time and can't really partake in project work due to that, which is demotivating our contributors - our next line of devs. A remote testing machine would help to "continue" between sessions enabling better interaction, and stronger workflow with our Github contributors. Since we do a thorough testing of any contribution before merging them, a laptop that's randomly open is not good enough. Sam has also implied his interest over this - probably to not make his laptop yell loudly when in uni classes ;) In an ideal world, I'd like to hook this machine to Github doing automated builds _when_ requested. Since there'd be a few security issues I can come up with when doing fully automated build tests. arzano, you're probably already working on something similar? Guide me to right direction!
+1 conceptually to have something that can spin short-lived build hosts for this. If you can spin up something that does not require persistent resources, you can use it on AWS in short order. Our AWS credits roll over on 2020/Oct/31, so make sure you have a backup of anything you do there, as we may have to delete resources in short order if the credits are not renewed (per terms of AWS credits, we can only apply for the renewal after the old credits have expired).
(In reply to Joonas Niilola from comment #0) > Hi, > > I'd like to either request access to some powerful amd64 hardware, or a new > instance to go through our Github pull requests. > > I'm currently using laptop most of the time and can't really partake in > project work due to that, which is demotivating our contributors - our next > line of devs. A remote testing machine would help to "continue" between > sessions enabling better interaction, and stronger workflow with our Github > contributors. Since we do a thorough testing of any contribution before > merging them, a laptop that's randomly open is not good enough. Sam has also > implied his interest over this - probably to not make his laptop yell loudly > when in uni classes ;) > > In an ideal world, I'd like to hook this machine to Github doing automated > builds _when_ requested. Since there'd be a few security issues I can come > up with when doing fully automated build tests. arzano, you're probably > already working on something similar? > > Guide me to right direction! +mgorny, It was my understanding that we already have CI that is run against PRs against ::gentoo on github (see: https://wiki.gentoo.org/wiki/Project:Repository_mirror_and_CI) How is this different from that, or is there some reason proxy-maint can't use it (I'm not intimately familiar with proxy-maints workflow.) -A
I'll answer: Yes, pkgcheck CI is run on PRs. However I'd like a hook that *testbuilds* the PRs as well. On demand. So you'd eyeball through the contribution to check any obvious mistakes in the ebuild, and to verify SRC_URI is not pointing to anywhere suspicious. Then you add a label or something which launces a buildbot that fetches the contribution and attempts to emerge it. Meanwhile a human can move on to another PR, or do whatever, but the automated buildbot is building the contribution. It'd then return OK or FAILURE that's visible in the PR with build.log, so the contributor can fix it. If OK, any member can then merge it to ::gentoo tree when they have time.
(In reply to Joonas Niilola from comment #3) > I'll answer: > > Yes, pkgcheck CI is run on PRs. However I'd like a hook that *testbuilds* > the PRs as well. On demand. > > So you'd eyeball through the contribution to check any obvious mistakes in > the ebuild, and to verify SRC_URI is not pointing to anywhere suspicious. > Then you add a label or something which launces a buildbot that fetches the > contribution and attempts to emerge it. Meanwhile a human can move on to > another PR, or do whatever, but the automated buildbot is building the > contribution. It'd then return OK or FAILURE that's visible in the PR with > build.log, so the contributor can fix it. If OK, any member can then merge > it to ::gentoo tree when they have time. So basically as a proof of concept we could: - Define a github action that is a build. - Create a workflow that runs that action. - Trigger that workflow either automatically (e.g. with the existing CI method), or manually (by proxy-maint.) - Run the runners on infra hosted by Gentoo (rather than github hosted runners.) Is this basically what you are looking for? Conceptually the questions I'd then ask are basically: - What is teh overlap with existing tinderboxing efforts (toralf and ago both run one; afaik.) - Can we all combine our efforts to produce something re-usable between the efforts themselves? - Provided we retain the AWS credits, that part is actually quite easy (we make a VM, enroll it as a github runner; install docker, done.) -A
Arzano and I have already planned the build CI which gonna test each and every commit to the gentoo.git in anyway.
(In reply to Alec Warner from comment #4) > > So basically as a proof of concept we could: > - Define a github action that is a build. > - Create a workflow that runs that action. > - Trigger that workflow either automatically (e.g. with the existing CI > method), or manually (by proxy-maint.) > - Run the runners on infra hosted by Gentoo (rather than github hosted > runners.) > > Is this basically what you are looking for? Yes, but it'd take time to set it all up. I'm currently also looking for an access to existing build machine, or a new instance for p-m team to test contributions manually. We can't keep up with the demand using our own PCs. > > Conceptually the questions I'd then ask are basically: > - What is teh overlap with existing tinderboxing efforts (toralf and ago > both run one; afaik.) toralf and ago test packages that end up in ::gentoo. This'd run the tests before anything is merged. > - Can we all combine our efforts to produce something re-usable between the > efforts themselves? Yes please. I'm delighted to see there's already an initiative for this by arzano and zlogene! Their plan is test everything that's merged, but it can probably be tuned to test non-dev contributions as well. > - Provided we retain the AWS credits, that part is actually quite easy (we > make a VM, enroll it as a github runner; install docker, done.) Sure, the method doesn't really matter. I'd favor LXD personally, but... I have no experience with docker, but zlogene seems to be onboard so no worries.
