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
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
It's a deprecated platform that has weird OpenGL-related bugs and
is incompatible with using EGL anyway. It was clear we're going
to drop it, the only question was when. Answer: now.
We're using gcov+lcov, since these tools appear to be the only
usable ones that use the SC/CC metric; and measuring just the line
coverage would be practically criminal negligence.
gcov only works with GCC and Clang, and MSVC's own coverage
measurement tools are not up to the task; so MSVC is out of luck.
This commit alters the build system substantially; it adds another
platform, `headless`, that provides stubs in place of all GUI
functions, and provides a library `solvespace_headless` alongside
the main executable. To cut down build times, only the few files
that have #if defined(HEADLESS) are built twice for the executable
and the library; the rest is grouped into a new `solvespace_cad`
library. It is not usable on its own and just serves for grouping.
This commit also gates the tests behind a -DENABLE_TESTS=ON CMake
option, ON by default (but suggested as OFF in the README so that
people don't ever have to install cairo to build the executable.)
The tests introduced in this commit are (so far) rudimentary,
although functional, and they serve as a stepping point towards
introducing coverage analysis.
It was never really needed, since both Linux and OS X, where
GlOffscreen is used, guarantee that the API we need is present,
on all OS versions we're interested in.
Also, reorganize GlOffscreen consistently with the rest of our
codebase, and don't use RAII for OpenGL resource management because
of its requirement for an active context.
Travis OS X builders randomly break in ways that aren't reproducible
outside of their VMs, have no Google hits, and are very aggravating;
the two common ones are:
* hdiutil: create failed - Resource busy
* make[2]: write error
This commit drags SNR back into a tolerable range with a gross hack.
Maximilian Federle
Koen Schmeets
наб
whitequark