[Libre-soc-dev] GitLab-CI fixes
j.neuschaefer at gmx.net
Tue May 4 22:09:30 BST 2021
On Tue, May 04, 2021 at 08:28:21PM +0100, Luke Kenneth Casson Leighton wrote:
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
> On Tue, May 4, 2021 at 5:50 PM Jonathan Neuschäfer
> <j.neuschaefer at gmx.net> wrote:
> > After recent discussions about the lack of CI, I spent some time bringing
> > the GitLab-CI configuration in soc.git back in shape. My work can be found at:
> > https://gitlab.com/neuschaefer/soc.git ci
> ah excellent, i just merged those, they look reasonable.
> > Short log up to commit 95c8acbdce34ed94010333deea93bedb0a32fffa:
> > Jonathan Neuschäfer (10):
> > .gitlab-ci.yml: Rewrite git://git.libre-riscv.org URLs to https://git.libre-soc.org/
> > .gitlab-ci.yml: Remove tags from nmigen-soc repo
> > .gitlab-ci.yml: Install Rust and cargo
> > .gitlab-ci.yml: Clone and build openpower-isa
> > .gitlab-ci.yml: Clone and build c4m-jtag
> > .gitlab-ci.yml: Clone and build power-instruction-analyzer
> > .gitlab-ci.yml: Fix invocation of pywriter
> > .gitlab-ci.yml: Trim log output
> > .gitlab-ci.yml: Silence pywriter harder
> > minerva tests: Don't import soc.minerva.csr
> > With these patches, the tests can run again. Many tests still fail or
> > run into errors (Python module not found, mostly; details attached), but
> > I think it's a good start.
> excellent. btw, 96k debug logs sent to the list, geeennnerally we
> don't do that, using e.g. pastebin somewhere and sending the link,
> instead. otherwise the server quickly runs out of disk space.
(With gzip compression it would have been merely 8k, but I think the
attachment was filtered by mailman)
> > I know that libre-soc.org won't switch to GitLab,
> insane loadavg, massive resource utilisation (at idle!), massive
> security-hole footprint, headaches all round. not happening.
> > and it doesn't have
> > to: A GitLab(-CI) instance can be run alongside git.libre-soc.org by
> > anyone who wants to spend the time/effort/money. I tested on gitlab.com
> > (until I ran out of my monthly free allowance of 300 minutes) and a
> > private GitLab instance.
> jacob does have one up and running on a machine behind the VPN connection.
Another thing: Depending on the hardware performance of the CI runner,
the timeout may need to be increased (patch now available in my ci
branch). For example, the job hits the one hour timeout on gitlab.com.
> i've never looked at these gitlab-ci things before. i'm curious as to
> why the dev-env-setup scripts are not used?
> this would avoid huge duplication of commands and also ensure that the
> dev-env-setup scripts themselves were tested.
Jacob might know why it is the way it is, but using dev-env-setup sounds
like a good refactoring to me.
More information about the Libre-soc-dev