Re: [PATCH v2 5/5] ci: add support for GitLab CI
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Oct 30, 2023, 10:46 UTC
- Message-ID
- <ZT-JdyEEgN3l7T5L@tanuki>
- In-Reply-To
- <8db10489-546d-428d-9b3e-7ecea87e1313@gmail.com>
On Sun, Oct 29, 2023 at 04:13:39PM +0000, Phillip Wood wrote:
Show 26 quoted lines
> Hi Patrick > > On 27/10/2023 14:02, Phillip Wood wrote: > > On 27/10/2023 12:57, Patrick Steinhardt wrote: > > > Hum. After having a look at `ci/run-docker-build.sh` I don't feel like > > > it's sensible to update it. It's not even used anymore by our CI but > > > only by `ci/run-docker.sh`, which seems to be more of a developer-facing > > > script? > > > > > > As you said, this smells like rotting bits that might rather be removed. > > > But in any case, as they don't relate to our current CI infrastructure > > > except for being in "ci/" I'll leave them be for now. > > > > I was trying to suggest that we start using these scripts again. > > Having taken a closer look I think we'd be better off adding something like > > # Ensure the build and tests run as an unprivileged user > if test "$(id -u)" -eq 0 > then > useradd --home-dir "$(pwd)" builder > chown -R builder . > exec sudo --preserve-env --set-home --user=builder "$0" > fi > > To the beginning of ci/run-build-and-tests.sh.
That indeed looks like a nice way to handle this, agreed. As mentioned though, I don't really have an easy way to test this with GitHub Workflows or Azure Pipelines. So I'd propose to defer this change to a follow-up patch series -- and in the best case somebody who is familiar with these CI solutions would pick it up rather than me.
Patrick