Trigger Release with tag 'releaseTrigger' #256
Conversation
This changes will trigger a build on master, when there is a tag 'releaseTrigger' created. It will notify our normal GitHub Actions, and retrigger a build. The payload will tell the our normal build, that this is a release, and it will trigger the build. Downside, this will only work in MASTER for now. If we want to support other branches, we need to use our combined brain power, how to retrieve a branch name from a git tag. It is not such a trivial problem.
Tags are not related to branches, but to commits.
Sure, same as of now
That made me think - can everyone create a tag and start a release? Or only maintainers, who have write permissions on the repo?
In my opinion it should be the last step of the process, so when the release was successful the tag is gone. |
This changes will trigger a build on master, when there is a tag 'releaseTrigger' created. It will notify our normal GitHub Actions, and retrigger a build. The payload will tell the our normal build, that this is a release, and it will trigger the build. Downside, this will only work in MASTER for now. If we want to support other branches, we need to use our combined brain power, how to retrieve a branch name from a git tag. It is not such a trivial problem.
…gAction # Conflicts: # .github/workflows/actions.yml # .github/workflows/releaseTrigger.yml
|
@beatngu13 as you are also deeper into this build pipeline issues, what do you think about this approach, splitting deployment into own yaml and waiting of all other suites which are github actions, to finish? |
There was a problem hiding this comment.
@beatngu13 as you are also deeper into this build pipeline issues, what do you think about this approach, splitting deployment into own yaml and waiting of all other suites which are github actions, to finish?
I haven't work with some of these actions, so I can't tell how they work in practice. But overall I like the approach very much and it appears to be a great fit for the targeted workflow. 👍
Co-authored-by: Daniel Kraus <daniel.kraus@mailbox.org>
|
Kudos, SonarCloud Quality Gate passed!
|
Migrate to new Shipkit plugins (#410 / #419) Shipkit is deprecated and the GitHub project[1] is archived. They write: > "One Shipkit Gradle plugin to rule them all" approach has proven > hard to maintain for the team. We [have] converted Shipkit into a > narrow set of small libraries (design note[2]). Several customers, > inclu[d]ing Mockito project have already migrated. More preecisely, Shipkit was split into these projects: * shipkit-auto-version[3] * shipkit-changelog[4] * shipkit-github-release (no source on GitHub?) This change updates the build accordingly. Closes: #410 Maybe solves: #256 (can't be determined without a release build) PR: #419 [1]: https://github.com/mockito/shipkit [2]: https://github.com/mockito/shipkit/blob/master/docs/design-specs/future-shipkit.md [3]: https://github.com/shipkit/shipkit-auto-version [4]: https://github.com/shipkit/shipkit-changelog
This changes will trigger a build on master,
when there is a tag 'releaseTrigger' created.
It will notify our normal GitHub Actions, and
retrigger a build. The payload will tell the
our normal build, that this is a release, and
it will trigger the build.
Downside, this will only work in MASTER for now.
If we want to support other branches, we need
to use our combined brain power, how to retrieve
a branch name from a git tag. It is not such
a trivial problem.
Questions:
I hereby agree to the terms of the JUnit Pioneer Contributor License Agreement.