On Thu, Dec 27 2018, Randall S. Becker wrote: > On December 27, 2018 17:40, Ævar Arnfjörð Bjarmason wrote: >> On Wed, Dec 26 2018, Randall S. Becker wrote: >> >> > Please stay tuned for patches. We are very much looking forward to >> > having the two (or three) different NonStop hardware personalities >> > supported without mods in the very near future. Our goal, assuming >> > those patches are acceptable, is to move our build/test/distro into a >> > Jenkins config that runs with minimal human involvement (a.k.a. me). >> >> Portability patches like that are definitely wanted. >> >> In case you haven't seen my recent work on getting GitLab CI up & running >> check out https://public- >> inbox.org/git/875zwm15k2.fsf@xxxxxxxxxxxxxxxxxxx/ >> >> It differs from existing CI implementations for git.git in being focused on >> doing the actual run on remote hosts that can be ssh'd to. >> >> So perhaps you'd be interested in some of: >> >> a) Contributing a NonStop box to the GCC Compile Farm >> (https://cfarm.tetaneutral.net/machines/list/). Then I can add it to >> my tests, but also other people porting free software will fix bugs >> pro-actively before you spot them. > > If I win the lottery, sure. Right now, a contribution like that is a bit beyond my budget. I'm not sure that anything "GCC" will fly with management since GCC does not port to the platform at all at this point in time. Many have tried. Many have failed. We're limited to c89 and c99. > >> b) I now have a gitlab-runner I maintain powering this git-ci.git stuff >> & presenting it on gitlab.com, if you give me SSH access I can add it >> to my own runs... > > Sorry, no can do on this one. > >> c) ...or you can just run your own gitlab-runner on >> https://gitlab.com/git-vcs/git-ci/ (although this amounts to giving >> me ssh access, since you'll be running my code).... > > This may be more possible. I've been considering putting up a GitLab instance but it's a matter of not having enough time. I have more than enough LXC ubuntu instances still available for something like that. FWIW it's gitlab-runner, not gitlab, you can run gitlab-runner (and I do) without installing any of the rest of gitlab. It's basically a daemon that sits in a loop polling to see if there's new jobs for it, So the extent of the setup is that I have a Debian box that has: vm ~ (master=) $ sudo grep -v token /etc/gitlab-runner/config.toml concurrent = 10 check_interval = 30 [[runners]] name = "gcc-farm" url = "https://gitlab.com/"; executor = "shell" [runners.cache] (Secret token pruned out), that's what sets it up as "gcc-farm" (see https://gitlab.com/git-vcs/git-ci/blob/master/.gitlab-ci.yml), which just runs this shellscript: https://gitlab.com/git-vcs/git-ci/blob/master/ci/gitlab/run-on-gcc-farm.sh I.e. for a given job name (it extracts the hostname from that) it ssh's to that machine after scp-ing a given git.git revision to it, compiles & tests, and all the output is then visible at : https://gitlab.com/git-vcs/git-ci/-/jobs?scope=finished I still need to write the rather trivial bit that'll run this as a cronjob and push as new git.git revs become available, but so far I've been wanting to get it passing 100% as a baseline, which hasn't happend due to wanting to handle transitory failures (e.g. ssh to some boxes timing out) and smoking out the various intermittent failures on some of the odd platforms/distro versions. >> d) ... or reuse the CI code I wrote to setup your own runner/pusher >> against NonStop, only you'd have access to this.... > > More likely. Private chat worth it perhaps. Sure, any time. >> e) Or do whatever you're planning with Jenkins. > > We are currently using Jenkins to build/test git. I was thinking about contributing a Jenkinsfile that would build on a Controller (what happens today for our git port), or setting up a parameterized form for SSH for an Agent that might be better in a farm setting. I am close to the point where human interaction is limited to 'git branch -f production vn.mm.l' and git is tested and built for distribution without further touching. At least once my platform patches are applied it will be. Makes sense, I thought you were just working on this as a new thing to do CI testing. >> If you want to just go with e) that's fine, just saying that you could re-use >> some existing stuff with a-d) if you wanted. > > I am interested. Let's see how my $DAYJOB goes in the next few months. I really do like the idea of setting up a community instance of GitLab to do this and include a CI runner. Hmmm. As noted above it's just a runner that's needed. I'm using gitlab.com's instance to present the results, I *could* also setup my own, but no reason to if they're willing to host it for free. B.t.w. I'm sure the same can be done with GitHub/Travis or Azure CI etc., I was just familiar with GitLab's, and wanted something where to begin with I could have my own overlay of custom CI on top of git.git without integrating patches upstream yet while I see if that even makes sense.
