They support cross-building to foreign architectures if the host
supports QEMU user mode emulation.

Well, support cross-building on amd64, to be precise. That's the dominant use-case but we could or should be more specific here.

This would have to be changed to an official image like solvespace/snapcraft: or whatever is preferable.

I propose registering an account on hub.docker.com and then connecting this repo. I'd either disable auto-builds or limit auto-building to very specific tags like e.g. docker/ec63361 so Docker Hub does not hammer out build after build for every unrelated change to master.

Thanks for the quick fix. Could you explain the exact relationship to Docker Hub? Are SolveSpace builds actually generated on Travis CI or Docker Hub?

We have to build in clean & minimal Ubuntu environments that conform to our declared base: core18, i.e. Ubuntu 18.04.

On Travis, we can only get Ubuntu 18.04 environments on amd64 and on arm64. This is problematic, as we also want to build for i386 and armhf. We can build for amd64 or arm64 though by disabling snapcraft's default mode of launching a VM, as launching a VM doesn't work on Travis.

Enter Docker: We take upstream's example Dockerfile and modify it, so that it creates a sane build environment for all four architectures.

As the Dockerfile is a mere description/recipe for building a Docker image, we have to build it before using said image.
We can do that in multiple ways:
a) on Travis, right before using that image to build the snap
b) manually on our computers and push the resulting images to Docker Hub
c) automatically by Docker Hub, which accesses our Dockerfiles and saves the resulting image for us to use later

The obvious choice here is c. We use Docker Hub as CD for our Docker images so we don't have to worry about them and to accelerate the builds on Travis, as we can simply pull the image from Dockerhub from then on before building the snap.

TL/DR: Docker Hub builds our Docker images that we need for snapcraft builds later. Docker Hub builds will be very rare, i.e. only when our Dockerfiles change. SolveSpace builds run on Travis and use those previously built images for clean environments in their respective target architecture.

as we can simply pull the image from Dockerhub from then on before building the snap.

Do you think it would be possible to use the Travis cache instead? This has a few advantages: fewer points of failure, no need to manage more credentials, the images are more obviously built from our Dockerfiles because there is no manual step that may introduce error, etc.

Yes. I think that's possible. I haven't played with any caching stuff so far, but I'll quickly find out whether that's viable.

I wonder whether we could just configure a foreign architecture in dpkg and force snapcraft's env variable SNAP_ARCH to that architecture. Then we could lose the Docker images altogether...

I'm in favor. In fact, I'm not sure if there is much point in supporting i386 and armhf anymore. For armhf, we have Raspberry Pi... does anyone actually do CAD on rpi? It's painfully slow if you're trying to do far simpler things. For i386, I'm not actually sure if people still run Linux 32-bit x86 systems. (Even Windows 32-bit x86 systems are dying out, though much slower so we still have to support them for a few years.)

That would be dead easy then. We can do amd64 and arm64 with --destructive-mode just fine on those stock images. i386 hmm. I'd say that's almost dead for desktop users.

Let's just drop i386 and armhf then. If someone actually requests them, we can do additional work to support those.

Right. A new PR then or shall I modify this one?

Let's modify this one.

While I'm at it: snapcraft has the concept of branches:

A branch is an optional finer subdivision of a channel for a published snap that allows for the creation of a short-lived sequences of snaps that can be pushed on demand by snap developers to help with fixes or temporary experimentation.

We could release builds for every PR to edge/pr<number> and people could install them easily for local testing.

We could release builds for every PR to edge/pr<number> and people could install them easily for local testing.

I think this would effectively expose snapcraft credentials to everyone, since they can just echo them in a PR Travis config.

Better yet, secure env vars aren't enabled in Travis on foreign PRs, such as this one, so they'd have to be present in every build log anyway.

I think that's it. Way easier and the required changes are minimal.

Wait--how are packages uploaded without credentials? Am I missing something?

Where do you see uploads?

I don't, that's what I don't understand. Shouldn't we upload the built packages to the Snap store?

From master, yes. From PRs, no.

Ah, you're talking about the launchpad credentials. Those were just for remote-build. SNAP_TOKEN ist still getting picked up in deploy-snap.sh

Ah sorry, was looking at an old checkout without deploy-snap.sh.