Thanks for bringing this to our attention. This isn’t really delta-related, but here’s what’s happening:
Your snapcraft.yaml contains:
This specifies where the snap may be run, not where it may be built. Currently, build.snapcraft.io assumes that all snaps can be built on
armhf, which is why three builders are triggered for each revision. There currently is no syntax in snapcraft.yaml to specify where a snap may be built. Once we have that, build.snapcraft.io will have to be updated accordingly. There is an ongoing discussion here about how we might implement such a feature.
Note that while having multiple
amd64 revisions built might be annoying for you (the developer), this won’t affect regular users since we build deltas based on what’s released to a channel, rather than what’s pushed to the store. In other words, you might have the wrong “from revision” installed (since you have access to non-released revisions), but you users can’t easily end up in that state.
Regarding download deltas, aside from some recent infrastructure issues we’ve been having, we’re not aware of any ongoing issues that can prevent deltas from being built. If you are having problems with download deltas, it helps us if you can provide the following information:
- When you released the new revision, what the new revision number is, what the snap-id is, and what channel(s) you released to.
- When you attempted to refresh (in UTC), what revision your client had installed (prior to refresh), what channel you were tracking, what revision the client ended up installing.
- What architecture the client is on.
As you can see, there’s a lot we need to know in order to pin down delta generation failures. So far we’re not aware of any client-affecting delta issues, but we’re always keen to hear from users that are having problems.