With arm64-graviton2 now providing full VM virtualization, LXD containers
can be used to build snaps on all architectures.
This is beneficial for us as having snapcraft manage the whole build
environment is likely to yield better/more consistent results than
running the builds on the Travis images directly.
Our implicit deploy conditions were previously only met by untagged commits
on master. As the stage conditions filter everything except branch = master
and tagged commits, we can just use all_branches: true to also deploy tagged
builds.
Also clean up the snap deploy sections.
With the recent Travis changes, we prevented the deploy
stage from running for tagged commits as branch=tag
for tagged commits. Fix this by also running deploy for
tagged commits.
Furthermore, clean up .travis.yml by pulling the edge
tagging logic into a separate script.
A logic change is introduced to prevent git tag --force being
run on set tags as this would turn annotated tags into
lightweight tags.
- Fix release notes by using edge deploy provider, see: https://github.com/travis-ci/dpl/pull/1069
- Deploy only on master branch
- Move to arm64-graviton2
- Rename debian -> ubuntu
- Remove appveyor.yml
- Remove redundant deploy stage in build step names
- Get rid of bash code in files using sh, and explicitly use bash in sign-macos.sh script
- Add missing newline to build-windows.sh
- Build x86 for Windows
- Enable OpenMP in test builds
- Disable sanitizers on macOS test build
- Disallow failures on snap build
- Fixes windows build type
- Revert `cleanup: false` back to `skip_cleanup: true`
- Waits 10 seconds to get notarize_uuid for macOS since it would sometimes fail
- Add OpenMP to macOS build
- Use as many cores as possible in CI
- Update travis osx image to xcode12.2
- Ignore .vscode folder
- In `.travis/sign-macos.sh`, only create keychain when `CI` variable is present
- Only run macOS deploy stage when a tag is pushed
arm64 builds on Travis are not yet fully mature and this
causes a high failure rate that is not caused by our code.
Continue building and deploying arm64 to the edge channel,
but don't consider the result for the success of the whole
build job.
Alleviates #587
Snapcraft's remote-build does not fit the requirements of CI,
so replace it with builds running directly on Travis:
1. Builds on Travis can run independently, whereas remote-build
competes for the same resource (Launchpad) and will potentially
block if multiple commits require building in succession.
2. Snapcrafts CLI for remote-build is not designed to be easily
scriptable.
3. Travis recently introduced building on arm64, so builds for
arm64 are now very fast and don't require emulation.
We do not build for armhf and i386 any more because they are
of little relevance on the desktop.
dpl-snap only supports pushing one snap at a time.
Instead of many repetitive deploy statements,
we use our own script to loop over the snaps to be released.
We invoke builds on Launchpad in stage "deploy" and release it into
the edge channel of the Snap Store.
The deploy stage is blocked on fails of the test stage, so we don't
release snaps with failing tests.
- Fix invalid osx_image xcode8.2
- Drop depreceated sudo keyword
- Run debian build on bionic image & re-enable building with ui
- Split build into separate jobs & stages for better separation of concerns
These are now handled through GitHub status changes, and so the one
notifico instance works just as well, and needs less configuration
in the repository.
We are going to use freetype instead of the old custom TTF parser,
since the old parser has many annoying bugs when handling non-Latin
fonts and fixing it is not really worth the time.
On Windows, Freetype is built from a submodule.
On Linux and OS X, Freetype is provided together with the desktop,
though development files have to be installed separately.
After this change, SolveSpace does not contain nonfree assets.
Additionally, Perl is not required for the build.
Note that in the US, case law suggests that copyright does
not apply to bitmap fonts:
http://www.renpy.org/wiki/renpy/misc/Bitmap_Fonts_and_Copyright
Nevertheless, it was prudent to replace the asset with something
that is unambiguously free.
Maximilian Federle
Koen Schmeets
whitequark