fyne-cross
fyne-cross copied to clipboard
fyne-io
Enhancement : private repositories
Allow to inject a .gitconfig in fyne-cross docker image to be able to pull from private repositories.
I’m not sure if this is the right solution. Isn’t it better to just vendor dependencies?
I'm not sure about vendoring, isn't it kindof less used now we have modules?
I'm not sure about vendoring, isn't it kindof less used now we have modules?
It is definitely used less often now but we have recommended it in the past when people have used replace directives in their module files. I figured that it would be useful here as well when there are private repositories at play.
Thoughts @lucor?
Vendoring could help but does not cover all use cases for example when the user won't or can't add the code to the repo (i.e. license aspects).
A possible to solution it to share the ssh agent between host and container but also this one probably won't be a definitive solution... thinking here about windows users or users that uses API token.
IMO we need to explore the integration with solutions provided by the engine (docker or podman), if any, like docker secrets
I think the only solution for now is to extends the fyne-cross image in our own Dockerfile, am I right ???
If for extending the docker image you mean add a ssh key and configure the ssh client, yes that would work but I won't add a ssh key to an image for security reasons.
Btw I'd have misread @Jacalz comment.
I was referring to push the vendor dependencies into a repo.
Vendoring the dependencies before cross-compiling should work.
Example: go mod vendor && fyne-cross linux
@itschrono does the above work for you?
The other possibility would be to mount $GOPATH/pkg inside the container and run go mod download prior to fyne-cross. The benefit compared to the vendor directory is that it doesn't introduce additional files inside the repository being built which could lead to tool getting confused when used outside of fyne-cross.
I agree @Bluebugs, add the possibility to share a GOMODCACHE directory between host and container and pre-fill the cache with go mod download could be a solution.
We already do a similar thing for GOCACHE.
The only downside of this approach (like the vendor one) is that the Go version between host and container could differ. It should not have any impact but we could not have reproducible build.
That is indeed a good point that I did forget about. Maybe for the moment adding a warning if both version do not match would help let the developer address the problem.
I wanted to point out a discovery I had today using go mod vendor. When building without vendor directory, only the dependencies that needs building are build (if you have a file that is for example protected to only be compiled with 1.18, it will not be compiled nor will any of its dependencies be on with older go version). Now when building with a vendor directory this is not anymore the case, all the dependencies inside the vendor directory get build and this will force some of those build that would have passed without a vendor directory to not pass with one.
I think it would be good to offer a way for the user to be able to enable GOMODCACHE/go mod download on the host when it feels like it would solve this case, maybe with a warning that it could lead to non reproducible build.
Just had a realization, to get access to private repository, we just need to get ssh keys from the outside of the container to the inside. That could be done quite transparently actually. We just need to check the existence of $SSH_AUTH_SOCK and if it does, we just need to mount it as a volume in the container and set the environment variable. Something like that need to be added on docker command line: -v $(readlink -f $SSH_AUTH_SOCK):/ssh-agent -e SSH_AUTH_SOCK=/ssh-agent.
I know it has been a long time in happening, but I just pushed a PR that if you have time testing might solve this long standing issue by propagating the ssh-agent socket inside the container.