search

jenkins-infra / github-reusable-workflows

Repository for reusable workflows
MIT License
1 stars 5 forks source link

add action to move major v tag #4

Closed jetersen closed 2 years ago

jetersen commented 2 years ago

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

jetersen commented 2 years ago

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

jetersen commented 2 years ago

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 commented 2 years ago

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

I guess this is a workaround for https://github.com/github-community/community/discussions/8088 ?

jetersen commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.