It is very strange that in some yaml files the $(<release-version) construct
works just fine, but in others it evaluates to an empty string, even though the
file is there an has the correct content.
Attempting to get more debugging info and also use a different expression to
extract the information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
They are now the four digit version dash build nr
So major.minor.patch.commitsSinceTag-buildNr
This makes it easier to correlate the release name and a specific manually
built version.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Prevent attempts to generate a build number for pull request builds as
they will fail due to the lack of permissions on the
`subsurface/nightly-builds` repository.
Signed-off-by: Michael Keller <github@ike.ch>
The necessary keys to do so aren't available (and of course we don't try
to post a release on pull requests, anyway).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
What a pain. It turns out that github.run_number is counting the number of
times a specific workflow has been run - but that's different for different
workflows, so using that won't get us a single tag with all the corresponding
build artifacts. And sadly I can't find a simple atomic way to increase a
GitHUb repo variable, so I came up with this somewhat convoluted dance, using
the the fact that a push to an existing brach that isn't a fast-forward will
fail.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way our ongoing releases will be in their own repo.
Also, use a nicer date format (at least I think this looks nicer).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We need some additional options when building the package, so let that script
handle the details and use the generic build script mainly for the dependencies.
Also let's not mix building for testing and building the DMG - just so I can
stay somewhat sane.
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>
In order to apply the patches for Kirigami, git insists on having
a valid user name and email.
Also, don't build the mobile app when preparing the AppImage. That
build already takes way too long and we test this in a few other
actions.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It is completely incomprehensible why these fail. And why randomly restarting
sometimes fixes them, and often doesn't. At this point there is no incremental
value in having this test. If it were to ever catch a real bug, we wouldn't
realize it because we are too well trained to ignore the problem.
Very disappointing, but IMHO the right thing to do.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way we should see the output and hopefully be able to figure
out why that silly test keeps randomly failing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no point in doing that since the app directory this creates is broken
on older macOS versions, anyway (and we create a working DMG through a
webhook).
Additionally, lately this has started to fail on GitHub, so let's just rip this
out.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As much as I hate having passwords exposed through the source code,
since GitHub wisely prevents reading secrets in pull requests, there
isn't really a sane way to have this use confidential credentials.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a bit more convoluted to do inside of the Ubuntu 19.10 container, but
at least for Ubuntu 14.04 and for Mac this will be an improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We now get a working macOS DMG for each CICD release via the webhook -
and the GitHub built .app.zip only worked on the latest macOS and was
near-unusable there.
We still make it available as an artifact of that macIS GitHub action in
case there is some value, but we no longer push it into the GitHub
release artifacts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Previously this created a bogus Subsurface.app.zip.zip file and then
failed to upload it to the release.
The upload / download pair of default actions is happier with just the folder.
And then the creation of the zip file needs the '-r' switch. Oops.
Finally, the pull-request specific uploads as build artifact are completely
redundant since we already do this to move the data from the macOS build to the
container that runs our own publish action in the first place.
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>
This feature is in beta right now and might change without notice, but instead
of dealing with the broken Travis Mac builds, this does seem progress.
The build artifact seems to work, but it's a bit more painful to get to. Go to
https://github.com/Subsurface-divelog/subsurface/actions and click on the
corresponding run - it's then in the top right corner under Artifacts. The one
oddity is that after unzipping the file you need to manually make
Contents/MacOS/Subsurface executable.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
