fix: latest tag logic in meta workflow

[k3rnelpan1c-dev]

Description

this is the backport PR

This PR aims to fix and introduce the latest tag logic from my prior CI PRs, sorry for any inconvenience that this error may have caused.

Issues

• fixes Latest tag on dockerhub points to snapshot instead of latest stable #1644 on default branch (the default branch PR is here fix: latest tag logic in meta workflow #1645)

[nscuro]

dependency-track/.github/workflows/_meta-build.yaml

Line 98 in 6520802

push: ${{ github.ref == 'refs/heads/master' }}

Means releases from the 4.5.x branch will never be pushed, no?

[k3rnelpan1c-dev]

good catch!

[nscuro]

Marking as "Request Changes" so it doesn't get merged accidentally.

[k3rnelpan1c-dev]

Okay, tiny problem with the separated workflows: No matter how I change it using the default GITHUB_TOKEN cannot be used to realise it ☹️

Note on GitHub Actions: You can use the default token which is provided in the secret GITHUB_TOKEN. However releases done with this token will NOT trigger release events to start other workflows.
If you have actions that trigger on newly created releases, please use a generated token for that and store it in your repository's secrets (any other name than GITHUB_TOKEN is fine).

So to say that I am stuck with that idea is quite accurate, unless we opt to setup a "Dependency-Track-Bot" account that will serve as PAT donor to create the release and commits to the projects on release.

re-posting here so we can discuss in an open PR instead of a closed one

[nscuro]

Hmmm... But triggering on new tags should work.

Creating a tag should be all that's needed to kick off the release pipeline. Once the tag is created, all following workflows, jobs and steps operate on the correct commit.

[k3rnelpan1c-dev]

Just like regular commits that are done by the 'GitHub Actions Bot' don't trigger regular push events, the same applies to tag pushes unfortunately 😞

[nscuro]

Damn. But yeah, makes sense. 😅

How about this:

• We decouple prepare-release to be run locally for now
• This can be done with mvn release:prepare which will set the appropriate release version, create and commit a tag, and set a new SNAPSHOT version
• Let the workflow trigger on new tags

We can still create a dedicated bot user and add a workflow that runs mvn release:prepare for us later.

[k3rnelpan1c-dev]

Damn. But yeah, makes sense. sweat_smile

How about this:

* We decouple `prepare-release` to be run locally for now

* This can be done with `mvn release:prepare` which will set the appropriate release version, create and commit a tag, and set a new SNAPSHOT version

* Let the workflow trigger on new tags

We can still create a dedicated bot user and add a workflow that runs mvn release:prepare for us later.

NGL, I had a similar thought, but not including any Maven release plugin 😅

We can still have 2 separate workflows as we would have (and what I already have ready in my fork, but on a different branch).

1. creates the GitHub Release and does the work to branch off where needed
2. assembles the war files and container to then upload to the GitHub Release

Gained benefits:

• you could still do the first part manually if you really wanted to, however the build would never involve an environment outside of GitHub.
• you don't need a separate PAT to trigger the second workflow

Lost benefits:

• you would have to trigger 2 workflows manually to finish a release

[nscuro]

Thank you for putting in all this work @k3rnelpan1c-dev.

I took a gander around your fork (the state on master looked like it's the most current). Few questions:

• You currently have ci-publish being triggered on new releases. Given the limitations you described earlier, I assume this works because you use a bot user w/ PAT to create releases?
• If we don't use a bot user to create a release, we'd have to run ci-publish manually from the release branch, which would be fine from my POV. However, because ci-release commits a new SNAPSHOT version after creating the release, we'd then build and publish a commit "after" our actual release commit. So we'd be building a SNAPSHOT?

[k3rnelpan1c-dev]

No worries! My motto: I caused the mess, I clean it up.

Yes the master in my fork is where I test to be as close to the real thing as I can be.

1. Yes the ci-publish workflow works cause I use my bot-user's PAT.
2. not quite, if I where to alter the workflow to run via a manual trigger as well, then you would trigger the ci-publish workflow with the git-tag to publish from. Thereby it would check out the exact tag the release was bound to and update the release that would be associated with that exact tag.

EDIT:
By doing this you can do what the ci-release workflow does on your machine and it would trigger the ci-publish via the release published event, or you run the ci-release and then trigger the ci-publish workflow manually on the release tag, or, finally, if we ever chose to use a BOT PAT that would be achievable automatically.

[nscuro]

Thanks for clarifying, sounds good to me.

[k3rnelpan1c-dev]

Okay, then I shall alter the changes as we discussed and get them into this PR.

note to self be sure to update the docs xD

[k3rnelpan1c-dev]

so this and #1645 are now ready for review.
I ran a couple of test scenarios on my fork again and so far was unable to find any glaring problems.

I tried to update the workflow documentation to the best of my ability, but feedback is very welcome 🙂

[nscuro]

Thanks so much @k3rnelpan1c-dev! Looks good so far, I'll play around with this later today on my fork.