In order to make it easier to see what's happening inside get-atomic-buildnr.sh
write the result to a file that can be read by the caller. Not quite as
elegant, but hopefully more practical to see what's going wrong when no new
build number is created.
Make sure that post-releasenotes is successfull by actually posting a release
artifact (apparently the gh release action otherwise quietly fails).
Try to ensure we find the Android APK when uploading to the release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Some experimentation showed what should have been obvious. The release
information is additive. So it's enough if ONE of the actions creates release
notes, all the others can simply add additional release artifacts.
To make this more obvious, this commit creates a new action that does nothing
but create the release notes and publish the release. Since it really doesn't
do anything else, it's likely to be the quickest to complete, but that doesn't
matter - the last action that has a body or body_path in the gh-release action
determines the release notes. And we now have exactly one action that does so.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of using a thirdparty action and painfully passing things around,
simply use the GitHub CLI (gh) and assemble the release notes on the fly.
This makes for much simpler and much easier to maintain code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- for now all versions start with v6.0
- CICD builds use the monolithic build number as patch level, e.g. v6.0.12345
- local builds use the following algorithm
- find the newest commit with a CICD build number that is included in the
working tree
- count the number of commits in the working tree since that commit
- if there are no commits since the last CICD build, the local build version
will be v6.0.12345-local
- if there are N commits since the last CICD build, it will be
v6.0.12345-N-local
- test builds in the CICD that don't create artifacts simply use a dummy release
in order to not incorrectly increment the build number and also not to waste
time and resources by manually checking out the nightly-build repo for each of
these builds.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Even on platforms that don't have the new git version, yet.
And using the convoluted way to create an environment variable that should
point to our checked out tree in the GitHub Action. The more obvious ways
have resulted in failed builds for obscure reasons.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Update README and ReleaseNotes.
Also remove outdated workflow badge, add a couple new one, and hack around a
rendering issue where the last character of longer workflow names gets
overwritten by the status - which resulted in the arguably most important info
(which Qt version) being hidden.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Update to Qt 5.12.10, latest OpenSSL, add QtChart, add other missing packages.
Also switch to gcc-7 as our statistics code requires better C++17 support than
what gcc-6 can offer.
This then creates trusty-qt512:1.1
Signed-off-by: Subsurface CI <dirk@hohndel.org>
Net net this has caused more problems than it solved. Too often binaries
were missing or broken. Instead 'release equivalent' binaries are now
consistently posted to downloads/test via a Webhook.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We never noticed this before, but during the build of the Trusty Qt5.12
container itself we create libdivecomputer include files and we ship them with
the container. And as the recent build failures after an incompatible API
change in libdivecomputer show, those include files are apparently used in this
build, not the ones that are newly created during the build.
Obviously the build container needs to be fixed, but as a quick workaround,
this should do.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
transfer.sh has suddenly started to time out. And for the rather
occasional need of having a binary to test from a PR, this should be
good enough.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should fix the odd double builds for people who create branches for
pull requests in the main repository.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This means that PRs from people using the main repo for their staging
branches will get both transfer.sh and a release.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I wonder if this will cause issues where the actions sometimes run
twice. But we'll deal with that rather than dealing with not having the
tests on pull requests.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This so far just works on push and hopefullt pull requests, not for tags
and therefore actual releases.
In order not to conflict with the binaries from Travis, I changed the
name to "ci-release" instead of "continuous".
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The AppImage works - I just need to figure out how to post releases. For now
it'a available on the Actions page as Artifact.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
