Make multiple improvements to the existing workflows:
- create a shared custom action to deal with version number tracking
and generation;
- use this action to add the branch name to the version for pull
request builds;
- create a shared workflow for all debian-ish builds to avoid re-use
by copy / paste;
- remove potential security risks by eliminating the use of
pre-evaluated expressions (`${{ ... }}`) inside scripts;
- update outdated GitHub action versions;
- improve the consistency by renaming scripts acording to have a `.sh`
extension;
- improve naming of generated artefacts for pull requests to include
the correct version.
@dirkh: Unfortunately this is potentially going to break builds when it is
merged, as there is no good way to 'test' a merge build short of
merging.
We'll just have to deal with the fallout of it in a follow-up pull
request.
Signed-off-by: Michael Keller <github@ike.ch>
Update the linux AppImage build to use ubuntu 16.04, and simplify it to
a single workflow running on a vanilla docker image.
This still uses the upload-artifact@v3 Action that will be EOL in
November 2024, because v4 relies on node 20 which has an unmet glibc
dependency in ubuntu 16.04. But this workflow can be updated to run on
ubuntu 18.04 by a simple search / replace and disabling some 16.04
specific PPAs.
@dirkh, @probonopd: I have moved this here from #4183 to be able to
review and discuss it without the noise of the workflow cleanup.
The workflow now also publishes the AppImage as an artifact on pull
request builds, available under Checks / Details / Summary.
Signed-off-by: Michael Keller <github@ike.ch>
Do a few things:
- add a build for Debian trixie (as discussed in #4182);
- add a build for Ubuntu 24.04;
- rename the build definitions to match the build names;
- update the artifact uploads to use a non-deprecated version of the
action, and name the artifact appropriately;
- remove a stale workflow file.
Signed-off-by: Michael Keller <github@ike.ch>
Do some housekeeping and cleanup on the build scripts for Windows:
- remove Windows 32bit builds as support for this has been removed from
the mxe container;
- fix some warnings in the smtk2ssrf installer configuration;
- sanitise the output colour of the smtk2ssrf build script;
- add a docker based build script for the Windows installers;
- remove outdated and deprecated documentation and scripts.
Signed-off-by: Michael Keller <mikeller@042.ch>
Add a script that finds the changeset ID in the subsurface repository
that a given CICD release was built from.
The option '-c' can be used to check out the changeset, if one is found.
Signed-off-by: Michael Keller <mikeller@042.ch>
Q_FOREACH and foreach are anachronisms.
Range based for may cause a performance regression: it can
lead to a copy of shared containers (one reason why Qt's
COW containers are broken). However, as long as there is no
user noticeable delay, there is no point in analyzing each case.
And also no point in slapping an 'asConst' on every container
that is looped over.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a file containing the release title (derived from the pull request
title / commit message) to CICD releases - this is so that it will be
able to pick this up by the process updating the release pages on our
webserver, and show a list of the last few changes for each release.
Signed-off-by: Michael Keller <mikeller@042.ch>
Move the GitHub Action that builds the Windows artefacts to use the new
subsurface/mxe-build:3.1.0 container.
Also rename references to the old container in scripts and
documantation.
Signed-off-by: Michael Keller <github@ike.ch>
Add a GitHub action that builds the docker image to run builds for the
Windows (MXE) version of Subsurface.
Also update the MXE image Dockerfile to the latest version of MXE, and
add a patch to use a current version of mdbtools.
Configure GitHub actions that do not build docker images to not trigger
on changes to the contents of `scripts/docker/`.
Signed-off-by: Michael Keller <github@ike.ch>
Current instruction to get the installer out the container will fail
with bash complaining about cp being a binary. Then would fail too
because subsurface-installer.exe doesn't exist any more.
Proposed instruction should work.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
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>
