lpci

~jugmac00/lpci:add-configuration-to-provide-packages-to-install

  1. Git
  2. lp:~jugmac00/lpci
  3. add-configuration-to-provide-packages...
Last commit made on 2021-11-29
Get this branch:
git clone -b add-configuration-to-provide-packages-to-install https://git.launchpad.net/~jugmac00/lpci
Only Jürgen Gmach can upload to this branch. If you are Jürgen Gmach please log in for upload directions.

Branch merges

Branch information

Name:
add-configuration-to-provide-packages-to-install
Repository:
lp:~jugmac00/lpci

Recent commits

ded4b1e... by Jürgen Gmach

Declare system package dependencies for jobs

a415214... by Jürgen Gmach

Declare snap dependencies for jobs

3b20d4b... by Colin Watson

Check arguments slightly more defensively

cff573f... by Colin Watson

Briefly document new option

616fd00... by Colin Watson

Allow unsetting values via dynamic-properties

eca7b06... by Colin Watson

Remove several unnecessary assertions

4be82d6... by Colin Watson

Simplify some tests

50c134a... by Colin Watson

Rename various things for clarity

bde16fc... by Colin Watson

Handle job output paths and properties

The main complexity here is in ensuring that paths extracted from
completed jobs can't escape the build tree, either directly or via
symlinks.

I added a `LocalExecuteRun` gadget because we now need to do some work
in the container via carefully-crafted `find` and `readlink`
subprocesses, and mocking those meant that we weren't really testing the
interesting bits. Now we at least do real subprocess execution in those
tests, albeit without a container.

`distribute`, `channels`, and `expires` will be implemented on the
Launchpad side.

4257002... by Colin Watson

Stop running lpcraft inside the container

I borrowed the previous approach from charmcraft, and initially thought
it would be useful enough to pay its way: if we needed to wrap the job
in any complex logic that would be difficult to do at arm's length from
outside the container, then the ability to run Python code inside the
container would be helpful.

However, this approach also has a number of disadvantages: injecting
lpcraft as a snap is complex and relatively slow; it incurs all kinds of
complexity spread over lpcraft; and the split between `_run_job` and
`_run_pipeline` wasn't very clearly motivated and was confusing.

Since there doesn't turn out to be a pressing practical need for all
this complexity, remove it, and instead just execute job commands
directly inside the container.