I had missed this one in commit d73e0a0fb4
("build-system/packaging: add bluez dependency for Linux builds").
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- use hidapi grantlee and mdbtools from MXE
- update MXE version to use QT 5.15, and pull in libzstd and CMake 3.17.3
- fix linking of winmm on windows build with new mxe
- add some instructions on building the container
- add some new dependancies from QT 5.15 to the packaging
- add a patch to MXE to Build qtconnectivity with native-win32-bluetooth
[Dirk Hohndel: small refactor]
Signed-off-by: Paul Buxton <paulbuxton.mail@googlemail.com>
Signed-off-by: Dirk Hohndel <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>
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>
This is no longer created using GitHub actions (but all the necessary
information is still included in this repo). We need to be able to
shrink this container so our GitHub Action runs don't run out of disk
space.
Adjust the path where the resulting binaries are found with this build.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Our builds fail because we are missing pkg-config.
I'm not quite sure if this is triggered by a new dependency or if pkg-config
used to be there and now isn't. Either way, this should hopefully fix things.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since the official Qt binaries can no longer be installed without disclosing
credentials (well, sure, that could be done through secrets), I decided that
we should go back to packaging just the part of the iOS Qt SDK that we need.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Something is seriously wrong with the default Ubuntu 18.04 environment
on GitHub Actions. C++ builds fail with very confusing messages about
C++11 support.
Switching to building in a Ubuntu 18.04 based container - that seems
redundant, but it fixes the problem.
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>
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>
This appears to prevent Bluetooth from working.
Fixes: #2370
Suggested-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also deal more gracefully with other potential bugs so that
we don't add an spurious '-' at the end if the branch is empty
for some reason (as that makes the image name invalid).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Really, this is just here to re-trigger that container build now
that things are merged and stage 2 will actually work...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
These are of course arbitrary. The Android container image for some
reason based its version number on the Qt version. Which may or may
not be a good idea. The other two had 0.x version numbers, so let's
move them to 1.0 for the first release that gets pushed to the
subsurface account on docker hub.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When triggered by a push event, the checkout action checks out the correct branch.
But without this change, the stage 2 action would always run on master.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Based on ideas from Anton - both the basic building of containers in the first
place as well as the workaround for the 6h build limit.
Because GitHub Actions are limited to 6 hours we split the creation of the MXE
container into two steps and push the intermediary container after stage 1 to
docker hub. Right now each of the steps takes about 3.5 hours, so hopefully
even with changes in the future this will continue to work.
This commit also introduces use of docker hub instead of GitHub's own registry
(since strangely right now GitHub actions cannot run containers from GitHub's
private registry).
In order for this to work, we need to have the docker credentials in secrets in
GitHub. As a result, only people who can create branches in our repository can
easily test changes to the container images. Others can modify the code to use
a different docker hub account and provide those secrets in their own GitHub
account. Not ideal, but of course we cannot allow every pull request to
potentially overwrite docker images in our "official" docker hub account.
Suggested-by: Anton Lundin <glance@acc.umu.se>
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>
I am at a loss for words. Especially as we didn't need those quotes in
the first place. What was I thinking?
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>
It is clear why this wasn't caught in my testing, but the bug should
have been really obvious simply reading through the code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is incredibly brute force, downloading a 3+GB installer and
installing all of the Qt/iOS binaries.
This first attempt is mainly to get an idea how long this will take and
if this will fit within the size constraints of the build VM. This
commit doesn't even try to build, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
