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>
No artifacts from this build are preserved, this is just to make sure
that we can still build the desktop version against Qt 5.9.
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>
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>
Add a file CHANGELOG.md in the root Subsurface directory
and track this file with the `-text merge=union` attribute.
This prevents merge conflicts if release notes are added
on top of the file by different commits.
Also, make ReleaseNotes/ReleaseNotes.txt point to that file.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Add a 'Documentation change' section to the PR body.
This instructs the PR submitter to edit the section
with notes for the team editing the documentation.
If a PR has such notes, a maintainer should then
apply the needs-documentation-change label, so
that the documentation team can easily filter
such PRs by label.
Suggested-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
1) Add new description types:
- 'Code cleanup'
- 'Build system change'
2) Add a 'Release note' section:
The idea with this is that if you make a change
which is worthy of a release note in ReleaseNotes.txt,
it would be best to outline it here but also in the .txt.
This basically means that the PR should also touch
ReleaseNotes.txt with an extra patch.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
.github/ISSUE_TEMPLATE.md will be used when the Github users
create new issues.
.github/PULL_REQUEST_TEMPLATE.md will be used when the Github users
create new pull requests.
The markdown supports HTML comments (<!-- comment -->), which
can instruct the Github user how to create a detailed PR or issue
report.
Most big Github projects use such templates and these can help
the collaborators to examine the PRs and ISSUES faster.
Fixes#598
Reviewed-by: Dirk Hohndel <dirk@hohndel.org>
Reviewed-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
