On Fri, Feb 25, 2022 at 05:49:39AM -0800, Andrea Bolognani wrote:
On Fri, Feb 25, 2022 at 12:30:08PM +0100, Erik Skultety wrote:
> On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote:
> > Do you have any high-level concerns about the ci/build approach I
> > vaguely described? The finer details are of course far from being set
> > in stone, but I think the overall idea is solid and we should aim for
> > it being implemented as we evolve our CI tooling.
>
> No, I think that was a solid proposal, I would probably think of along those
> lines as well had I ever come to that idea myself :).
> Having each repo define their own build script which can be consumed both
> during local test executions and copied to the Dockerfile for a gitlab job to
> consume makes complete sense.
Just to make sure we're on the same page, what do you mean by "copied
to the Dockerfile"? The CI job can call the script directly from the
local clone of the repository just like a developer would on their
machine - no copying necessary. The Dockerfile describes the
environment a build will happen in, not the build steps.
> Top it off with something like 'lcitool container --script
> <path_to_build_script>' and I think we have a solid ground for future
work.
We're stepping into premature bikeshedding territory here :) but I
would expect this to look like 'lcitool build $target --container' or
something along those lines.
I've never got on very well with the 'lcitool build' command as its
a bit of a black box you don't have much control over. In its current
impl, it also means that lcitool has to know about build commands for
each project which is unfortunate.
If we're going to wire up support for containers, I think we should
start by just creating a 'lcitool run $target-or-host' command that
brings up an environment with an interactive shell, with the current
source present. eg
$ lcitool run fedora-35
We could then let it take a command + args to run as extra args
eg
$ lcitool run fedora-35 meson build
$ lcitool run fedora-35 ninja -C build
would just work with VM, but for containers you would need the
container FS to be persistent across runs. This could be achieved
by giving the container an explicit name, so you just re-restart
the same container each time instead of using a throwaway container.
The basic idea though is that running stuff inside the container/VM
is just the same as running stuff in your local checkout. The exact
same command name(s0, just prefixed with 'lcitool run fedora-35'.
Or in my case I'd add an alias
alias f35='lcitool run fedora-35'
so i can do
$ f35 meson build
$ f35 ninja -C bujld
etc
Regards,
Daniel
--
|:
https://berrange.com -o-
https://www.flickr.com/photos/dberrange :|
|:
https://libvirt.org -o-
https://fstop138.berrange.com :|
|:
https://entangle-photo.org -o-
https://www.instagram.com/dberrange :|