My team wants to move to snapcraft 3 using bases but we use mainly private repositories. Because the guest builds (multipass or lxd) don’t have access to host configuration pulling fails.
Is there any good way to solve this?
Related:
You can always set up alternate repositories in the guest environment, I don’t think that’s a problem.
You could inject the necessary configuration into the lxd / multipass container as they’re stood up. I know lxd can be modified before the container starts, because I did this in order to inject proxy configuration to the container I’m building in.
There’s a lxc profile set default series of options you can fiddle for example.
The changes in the default LXD profile doesn’t seem to apply to containers created using --use-lxd IIRC.
Do you mean by adding config to the guest as a build step outside of snapcraft? This was one of the approaches I thought about but it seems a bit messy. The other was to pull the repos outside of snapcraft in a separate build step automated with make. Personally I think I prefer the latter approach.
You can craft a new part to install alternate APT repositories and refresh the local package cache before running other parts that requires the alternate packages.
Ah sorry I’m referring to source code repositories and package repositories that require passwords or keys. Things like private github or private launchpad repositories.
4 Likes
Maybe a feature to run pulls outside the guest vm and copy the result could be added?
That’s entirely do-able already. You could clone your private repos into a folder in a project directory containing only the snap/snapcraft.yaml. Then the source lines for each of the parts just needs to point to those local directories. Then run snapcraft and it will stand up the VM and copy into the machine, everything necessary, assuming it’s all cloned into the directory containing snap/.
I am more inclined to have a way to pass credentials or VCS (including ssh) into the environments.
This could be as simple as mounting .ssh .git and such into the build environments or parametrize somehow through the snapcraft cli.
While I haven’t tried yet, when using LXD, you could coherse the default profile to add those disk devices by default, snapcraft will not care (we will be moving to a snapcraft specific lxd profile, and maybe use the project feature, in the future to make this a bit more manageable).
5 Likes
I think it’s super dangerous to advise users to change their default LXD profile to mount secret-containing directories into their containers.
One reason to use containers is for isolation, keeping potentially malicious software into a box, and changing the default profile seems reckless.
I do not think I was advising, just mentioning it was possible.
I wouldn’t do this myself, I am more of the preference to stay out of the business of supporting private repositories from the snapcraft workflow and have it provided through external mechanisms (clone/checkout/branch before coming into snapcraft)
I use the override scriptlets to achieve this. It depends on your level of security, but I store a read-only ssh key for my repo along with snapcraft.yaml (or could echo to file in scriptlet itself), then do something like this:
override-pull: |
chmod 600 $SNAPCRAFT_PROJECT_DIR/src/key/snapcraft
git config --global core.sshCommand "/usr/bin/ssh -i $SNAPCRAFT_PROJECT_DIR/src/key/snapcraft"
snapcraftctl pullThere is a new --bind-ssh option which will let you bind your host .ssh into the container for LXD and multipass.
3 Likes
which doesn’t do a job? Actually those half-working solutions from a canonical is unfortunately a “good tradition”. I’m here, cause in 2023 I can’t authenticate myself with SSH because no clear way to do that… or might not work with snapcraft new version (7?) or with new core22 base … or simply a bug … what a disaster this is
1 Like
Hello, I recently added two how-to guides about working with snapcraft and private repositories:
Any feedback is appreciated!
1 Like