Support for private repositories


#1

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:



#2

You can always set up alternate repositories in the guest environment, I don’t think that’s a problem.


#3

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.


#4

The changes in the default LXD profile doesn’t seem to apply to containers created using --use-lxd IIRC.


#5

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.


#6

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.


#7

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.


#8

Maybe a feature to run pulls outside the guest vm and copy the result could be added?


#9

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/.


#10

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).


#11

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.


#12

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)