That was the whole point of the previous change.
Also, run the build number creation on a pull request as well (at least for a
while) so we don't need to create new releases in order to test that part of
the process).
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>
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>
The get-or-create-buildnr.sh script writes a nice message to stdout which is useful
when using it interactively - but it broke the scripting; so redirect that output.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Move both code and the release note text into files that can be shared between
multiple actions.
This should make the actions smaller and easier to read and since this is used
in several actions it should make things much easier to maintain.
In order to test this without too much unnecessary noise, this commit only
changes the android workflow - the others will be changed in a later commit
once his has been tested and works (again, this can really only be tested by
merging the PR into master).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Move around the scripts required for the setup of the build environment
for android to satisfy docker's requirement of locality.
This allows the removal of an extra copy step, and avoids the creation
of extra artefacts, while still providing the same functionality.
Signed-off-by: Michael Keller <github@ike.ch>
Update the android build docker image:
- rebase on ubuntu 22.04;
- add tooling required to sign APKs;
- changes to make the container re-usable;
- change to a multi-stage build to keep the image size smaller;
- generic improvements to the Dockerfile
Also update the example script for how to use the container.
Signed-off-by: Michael Keller <github@ike.ch>
- 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>
Original mdbtools developer gave up the project some time ago, and it's
continued with his permission in a forked repo:
https://github.com/mdbtools/mdbtools.git
There was a nasty bug in libmdb, triggered under some rare circustances,
that is solved in the new repo which is, BTW, under current
development.
Move our scripts to the new repo and set our working version to the
latest release tag, currently, "v1.0.0"
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
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>
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>
It's unclear if this will be enough to use gcc 10 by default when building
Subsurface using this container.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It looks like Qt company has LGPLed versions tagged wich simplifies
things a bit while building, e.g. 5.15.3 current workaround matches
"v5.15.3-lts-lgpl" tag.
Background: Debian Sid is currently at Qt 5.15.8 which is impossible to
build from scratch with current script as only a few git versions are
tagged in the script format "v5.15.8".
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Update to match Xcode command-line-tools SDKs from 10.X to 16.X
Signed-off-by: Doug Junkins <douglas.junkins@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
-build-with-qt6 did not work for me, because the flag is
ignored when selecting the qmake executable. It would find
the system-wide qmake executable, which is Qt5 and then
decide to build with Qt5.
When the flag is set, try to search for a Qt6 version of
qmake first. On Ubuntu based distros this seems to be
qmake6
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The Qt Company apparently didn't feel the need to have the correct
tags in all of the module directories. So this now has to manually
pick the correct SHA. What a pain.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It does seem a bit odd, but the arch command actually doesn't
return a reasonable architecture on macOS. So let's use the
uname -m command to get the right answer that makes this script
work both on an m1 and an Intel Mac.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As some Linux distros start to ship both Qt5 and Qt6, it actually makes more
sense to build only against Qt6 when the user explicitly asks for it. Having it
preferred over Qt5 seems completely wrong in hind sight.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I couldn't make this to work as a single pass build, so we again do a dual pass
and manually assemble the dylib. This is then copied to a sane spot which
required another attempt to copy it in the CMakeLists.txt - which I added
comments to in order to make sense of the weirdness.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a flag to explicitly enable a build against maps, which is
only needed for Qt6 (as we always assume that Qt5 has maps installed).
It also includes a quick fix to fail gracefully if libmtp was already
patched.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As of today, GitHub no longer allows the 'git://' protocol, so we need to
switch the submodule and our other references to cloning git repos to
'https://' instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This has bugged me forever. The existing file creates a warning on every single
compiler invocation. I really need to figure out if I can get this fixed
upstream. But while I'm at it, I submitted it here to make it easier to spot
warnings in the build output.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we are building our own version of libusb, let's build a current one
(because current libmtp relies on that).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the CMAKE_PREFIX_PATH is a multi element path the old code failed
in very predictable ways. So instead simply fall back on the PATH to
find qmake.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This cleans up the script a little and makes it more flexible to add other
output formats; and adds Markdown as one such format.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
