Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Snap Travis integration #483

Closed
ppd opened this issue Sep 11, 2019 · 9 comments
Closed

Snap Travis integration #483

ppd opened this issue Sep 11, 2019 · 9 comments
Labels
internals Linux

Comments

@ppd
Copy link
Member

ppd commented Sep 11, 2019 •
edited

As outlined in #436 we'd like to have build on commit and also release to the edge channel.

Using snapcraft remote-build

The current plan involves using snapcraft remote-build to build for all possible architectures. This feature is still in beta @ https://github.com/snapcore/snapcraft/tree/remote-build and will receive further simplifications, so I propose waiting for that to be properly finished.

A sample implementation is here: https://github.com/ppd1990/solvespace-travis

Using docker

If that does not work out so well for any reason, we can still use docker to build for Travis' native architectures #436 (comment)

Cross-builds for other architectures should be possible with qemu, but I haven't looked into that enough.

Multiarch support for docker: https://github.com/multiarch/qemu-user-static
Travis with Docker and QEMU: https://developer.ibm.com/linuxonpower/2017/07/28/travis-multi-architecture-ci-workflow/

Architectures to support

It wouldn't hurt to define what architectures we'd like to build for. amd64 and i386for sure, armhf and arm64 make sense too for a desktop application.
@ppd
Copy link
Member Author

ppd commented Oct 30, 2019

And here we go: https://forum.snapcraft.io/t/call-for-testing-snapcraft-3-9/13944

Snapcraft 3.9 is pre-released and includes remote-build support. Let's do it.

@whitequark
Copy link
Contributor

Sounds good. Let me know once it becomes stable.

@ppd
Copy link
Member Author

ppd commented Nov 23, 2019

Certainly. We're going to need a solvespace launchpad account for remote builds though. I'll test with mine in the meantime

@ppd
Copy link
Member Author

ppd commented Nov 23, 2019

Is there a particular reason for dist: trusty? The Travis snap addon requires xenial or above and I'd rather use that if possible.

@whitequark
Copy link
Contributor

I don't recall if there was. It should be fine to upgrade to Xenial.

@ppd ppd mentioned this issue Nov 24, 2019
Closed
5 tasks
@ppd
Copy link
Member Author

ppd commented Jan 23, 2020

This was implemented by:

  1. a60d4df
  2. d5351c4
  3. 2dcd81d

Snaps are being built and deployed correctly: https://travis-ci.org/solvespace/solvespace/jobs/640723069

I consider this completed.

@whitequark
Copy link
Contributor

Is this process supposed to upload 4 separate releases, each supporting 1 architecture? Seems suboptimal.

@ppd
Copy link
Member Author

ppd commented Jan 23, 2020 •
edited

The revision is a strictly increasing integer per project and applies to all uploaded snaps. So yes, it is indeed meant to be that way.

See qelectrotech's revision matrix for example, which uses Canonical's "zero-config" https://snapcraft.io/build service:

Screenshot from 2020-01-23 15-29-37

So, not specific to our implementation; just the nature of the beast.

@whitequark
Copy link
Contributor

We're all done here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
internals Linux
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@whitequark @ppd