The architecture constraints are due to the way launchpad buildd behaves when it is defined in snapcraft.yaml
We can certainly work it out, but it requires work on both ends.
Is this feature still available in the beta/remote-build channel? Currently got 3.7 installed but can’t seem to call it:
$ snapcraft remote-build --arch=amd64
Usage: snapcraft [OPTIONS] COMMAND [ARGS]...
Error: No such command "remote-build".
Still a beta feature
2 Likes
I don’t see this option in 3.8+git15.g88b13cb (from beta/remote-build)?
This functionality has been removed for one that just does the right thing.
The overall idea looks interesting, is there a way to keep the source code private ? We have a close-source project that we would like to publish for all arches but can’t because build.snapcraft.io does not support that.
At this time, we do not yet have support for private projects, sorry!
It’s on our radar, but I don’t expect it to be available in the near future. Though if someone knows differently, feel free to chime in 
Is this option still available? It isn’t listed under snapcraft remote-build --help
If so, that’s useful. But if I want to build my working tree rather than HEAD (with un-staged or uncommited changes), is there a way to tell it to exclude some files?
I’m thinking particularly about node_modules which is very large and gets packaged and uploaded unnecessarily. I note that .snap files don’t get uploaded (clever), so I wondered if it’s possible to exclude other files, like with .gitignore?
It existed in the feature preview, but the interface was changed for the stable release. @cjp256, is there a way to do what @benfrancis is describing with the current release?
1 Like
snapcraft remote-build will tarball up your sources, including the .git directory, if present. --git is no longer required.
Unfortunately, there is no filtering - if you don’t want to include certain files, I’d suggest (re)moving them prior to the build. This matches the behavior for non-remote snapcraft operation when pointing to local sources.
@benfrancis If you would like, consider filing a feature request (https://bugs.launchpad.net/snapcraft/+filebug). Maybe we can support a --apply-gitignore or similar flag in the future.
1 Like
It appears that remote-build currently clones HEAD, which isn’t what I thought it used to do. How do I get it to build my working tree?
EDIT: It doesn’t even clone the HEAD of the current branch, it appears to clone the master branch. Even when I specify --package-all-sources
Blockquote[quote=“benfrancis, post:18, topic:11541”]
It appears thatremote-buildcurrently clones HEAD
[/quote]
Is your project source-type: git but referring to a local git repo (e.g. source: .)? If that’s the case, it will tar up your working directory. If it’s a remote git repo, it should honor source-branch|tag|commit
Ah OK, thank you. It was set to a remote GitHub URL.
Is it my imagination or did this behaviour change? I don’t remember having to modify snapcraft.yaml to get it to package my local working tree before. If so, when did it change?
Before it would only package up git sources if you specified --package-all-sources.
Previously there was a bug where local git sources were not accounted for. Now it will package up git sources if it is local (to match expected behavior).
Though behavior shouldn’t have changed if your source points to a github URL (Snapcraft will simply pass through the remote unless you specified --package-all-sources).
If that’s not the behavior you are seeing, can you share your yaml?
Thanks @cjp256, that is the behaviour I’m seeing, it’s just not what I thought the behaviour used to be.
I thought that previously remote-build would ignore the remote GitHub URL and package and upload my local working tree by default. That’s why remote-build was useful to me, because I wouldn’t have to commit my changes to GitHub before testing them (those changes were already built automatically when committed to master using the GitHub webhook)! You can see from the discussion above that it was previously also packaging up and uploading files included in .gitignore like my node_modules directory, which I didn’t want.
But perhaps I am misremembering and I had always modified snapcraft.yaml to point at my local source.
So anyway, it seems like what I need to do is edit my snapcraft.yaml to point to a local source during development and remember to change it back again before committing my changes.
If your snapcraft.yaml is in the same git repository that you are linking to by full path in source: configuration then you might find using . as a better solution generally - that is unless you need to clone a specific branch or tag to build via the build service, because the build service will always clone the default branch to get the yaml.
1 Like
Oh, thanks! Will that take into account snapcraft.yaml being in the snapcraft/ subdirectory of the repo or does it need to be ../?
for the build service to see it, I believe it needs to be either at ./snap/snapcraft.yaml or ./.snapcraft.yml (that is beginning with a dot if it is in the root directory)
There is another location supported but I can’t remember what that path is - something like ./packaging/snap/snapcraft.yaml but that’s a sheer guess. 
Sorry, I meant snap/, not snapcraft/
The point not being whether the build service can find snapcraft.yaml, but whether remote-build can find the source code one directory level up from snapcraft.yaml in the local working tree?
I will test it.
yes, using remote-build from the top-level project directory, not inside snap/, will work fine.
1 Like