add action to move major v tag

[jetersen]

This allows us to not manually bump major v tag after releases.

[jglick]

Fine if it works.

[jetersen]

@jglick I been using a version of it over at https://github.com/release-drafter/release-drafter/blob/master/.github/workflows/release.yml

[jetersen]

Worked flawlessly: https://github.com/jenkins-infra/github-reusable-workflows/runs/6870418421?check_suite_focus=true

I modified this version to allow us to also manually revert major version to any semver version tag 👏

[jtnord]

I came to this from a PR to use this workflow in my plugin.

I guess this is a workaround for community/community#8088 ?

[jetersen]

moving the v1 around is very common github action practice to allow reverting an issue with action.

This workflow allows easy bumping of the v1 after a release is published.

But ya the fact that dependabot does not support reusable workflows yet is another issue indeed.
Which the v1 tag also solves.

[jglick]

For this sort of workflow we use a floating tag because it only runs on trunk pushes. Thus it would not be of much help to allow Dependabot to bump a specific tag in a PR so you could verify that the workflow update was compatible with your plugin; the PR would pass (assuming tests are not flaky) even if the workflow were totally broken. Instead we rely on action maintainers to pay attention to regressions encountered in the wild.

[jtnord]

For this sort of workflow we use a floating tag because it only runs on trunk pushes. Thus it would not be of much help to allow Dependabot to bump a specific tag in a PR so you could verify that the workflow update was compatible with your plugin; the PR would pass (assuming tests are not flaky) even if the workflow were totally broken. Instead we rely on action maintainers to pay attention to regressions encountered in the wild.

My concern is not the PR and its status but that changes to my build and release configuration happen outside of my control and unknown to me as a plugin author.

Should I care? yes
should I be impacted, hopefully not

but that is not the argument. Just like i should be aware if my javadoc is published in java11 format or java 8, that is something I should be aware of as a plugin maintainer, not find out or discover randomly.
Or new interesting categories are added I can use
Or....

GitOps for the win.

I have been looking at renovate and I think this can handle updating shared workflows. I just need to try it out

[jglick]

changes to my build and release configuration happen outside of my control and unknown to me

Actually this is already the case for buildPlugin(), which is much more likely to directly affect you. The CD release workflow is deliberately kept very simple and without customizable knobs.

I have been looking at renovate and I think this can handle updating shared workflows.

Well so can Dependabot. The point is that we do not want to pin versions of this workflow because we expect that the resulting PRs will just be noise—they will be green and get merged without much thought, nor do we expect changes to be interesting to repository maintainers. Nothing is stopping you from pinning a version in your repository and letting Dependabot keep it fresh.

[jetersen]

Again it is optional you can continue using the workflow as is and close my PR. I do not care, I wanted to provide a service to help plugin maintainers whether they accept it is up to them.