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....@evledraar.gmail.com/ >> >> 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.
