mifr/subsurface
1
0
Fork 0
mirror of https://github.com/subsurface/subsurface.git synced 2024-12-04 16:11:28 +00:00
Code Issues Projects Releases Packages Wiki Activity
subsurface/.github/workflows/post-releasenotes.yml

39 lines
1.2 KiB
YAML
Raw Normal View History

build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
name: Post Release
on:
push:
CICD: Add GitHub Action to build the Windows (MXE) Builder Docker Image. 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>
2024-01-20 12:07:33 +00:00
paths-ignore:
- scripts/docker/**
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
branches:
- master
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
jobs:
postRelease:
runs-on: ubuntu-latest
steps:
- name: checkout sources
build-system: small changes for better debugging 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>
2024-01-10 15:11:27 +00:00
uses: actions/checkout@v4
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
build-system: don't discard the get-or-create-build-nr script output 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>
2024-01-10 20:38:46 +00:00
# since we are running this step on a pull request, we will skip build numbers in releases
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
- name: atomically create or retrieve the build number and assemble release notes
id: version_number
run: |
build-system: small changes for better debugging 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>
2024-01-10 15:11:27 +00:00
bash -x ./scripts/get-atomic-buildnr.sh ${{ github.sha }} ${{ secrets.NIGHTLY_BUILDS }} "CICD-release"
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
bash scripts/create-releasenotes.sh ${{ github.event.head_commit.id }}
CICD: attempt to read file content in GH yaml 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>
2024-01-11 01:13:17 +00:00
version=$(cat release-version)
build-system: use GitHub Actions outputs Tempting as it is to think this is just like bash - yaml isn't bash at all. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2024-01-10 21:02:48 +00:00
echo "version=$version" >> $GITHUB_OUTPUT
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
build-system: small changes for better debugging 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>
2024-01-10 15:11:27 +00:00
# ironically, we have to upload a file, otherwise this won't create a release with just the release notes
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
- name: publish release
build-system: don't discard the get-or-create-build-nr script output 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>
2024-01-10 20:38:46 +00:00
if: github.event_name == 'push'
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
uses: softprops/action-gh-release@v1
with:
build-system: use GitHub Actions outputs Tempting as it is to think this is just like bash - yaml isn't bash at all. Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2024-01-10 21:02:48 +00:00
tag_name: v${{ steps.version_number.outputs.version }}
CICD: Make it Possible to Run CICD Builds in a Fork. Use the project name to resolve the target repository to create the release in. Signed-off-by: Michael Keller <mikeller@042.ch>
2024-01-11 00:03:11 +00:00
repository: ${{ github.repository_owner }}/nightly-builds
build-system: create release notes only once 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>
2024-01-10 14:48:23 +00:00
token: ${{ secrets.NIGHTLY_BUILDS }}
prerelease: false
CICD: Improve the Release Note Generation Use .md suffix to get the files displayed as markdown. Ignore generated artefacts. Signed-off-by: Michael Keller <mikeller@042.ch>
2024-01-09 20:11:51 +00:00
files: gh_release_notes.md
build-system: missed one release note mention without .md Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2024-01-16 01:42:03 +00:00
body_path: gh_release_notes.md
Reference in a new issue Copy permalink