setup maven cd workflow #1

jetersen · 2022-05-13T06:01:51Z

fixes jenkins-infra/jenkins-maven-cd-action#10

jetersen · 2022-05-13T06:16:46Z

@lemeurherve who had you intended to review this, with write access 😅

jetersen · 2022-05-13T06:17:47Z

.github/workflows/maven-cd.yml

@@ -0,0 +1,65 @@
+# Note: additional setup is required, see https://www.jenkins.io/redirect/continuous-delivery-of-plugins


.github/workflows/maven-cd.yml not sure if maven-cd is the best filename for this workflow

i think is fine

although gradle could likely be supported in the same workflow, the actions would just need a flag, it just doesn't support it atm

Gradle CD would need to use a different versioning scheme and it could follow a different flow. I would stick to maven-cd. If and when some Gradle user wishes to introduce their own reusable CD flow, they can figure out how to refactor things to share parts of this one, or not.

jetersen · 2022-05-13T06:20:24Z

Seems to work as intended:
First use: https://github.com/jenkinsci/gitlab-api-plugin/actions/runs/2317760237
Making a release: https://github.com/jenkinsci/gitlab-api-plugin/actions/runs/2317774691
Actual release: https://github.com/jenkinsci/gitlab-api-plugin/releases/tag/5.0.1-72.vb_8c272862e86

.github/workflows/maven-cd.yml

jetersen · 2022-05-13T06:24:09Z

@jglick the question becomes do we want versioning on our reusable workflows?

My suggestion has been to point to main and never look back. Because it allows infra team to fix the workflow if something broke and distribute fixes to workflows faster.

timja · 2022-05-13T06:44:33Z

README.md

@@ -1,2 +1,3 @@
 # github-reusable-workflows
+


add an example of calling it?

I think it would suffice to edit https://github.com/jenkinsci/.github/blob/1292a5224fbc08abedc30408c14f71e804c95bbb/workflow-templates/cd.yaml#L11-L61

timja · 2022-05-13T06:45:14Z

@jglick the question becomes do we want versioning on our reusable workflows?

My suggestion has been to point to main and never look back. Because it allows infra team to fix the workflow if something broke and distribute fixes to workflows faster.

pinning to main should be fine for this, you can always pin to a commit if something breaks.

timja · 2022-05-13T06:46:06Z

cc @NotMyFault and @olamy who were looking at similar for release drafter and maybe crowdin

daniel-beck · 2022-05-13T12:00:23Z

pinning to main should be fine for this, you can always pin to a commit if something breaks.

Better hope you never have to evolve a workflow in a backward incompatible way. Took me just 11 days for jenkins-security-scan 😅

timja · 2022-05-13T12:10:13Z

pinning to main should be fine for this, you can always pin to a commit if something breaks.

Better hope you never have to evolve a workflow in a backward incompatible way. Took me just 11 days for jenkins-security-scan 😅

we do the same with buildPlugin.
Generally send PRs to consumers.

Not ideal but a lot less maintenance for maintainers.

Far less dependabot spam

timja · 2022-05-13T12:35:50Z

@daniel-beck reminded me that you can move tags around etc.

What he did with security scan was have a v1 tag and then when he did a breaking change he added a v2 tag.

which may be a better option?

daniel-beck · 2022-05-13T12:36:36Z

What he did with security scan was have a v1 tag and then when he did a breaking change he added a v2 tag.

And I kept updating each tag to point to the newest commit that made sense. So some management overhead is involved.

Only makes sense when you have one repo per workflow though.

jglick · 2022-05-13T15:23:27Z

I (probably) would recommend pinning versions for buildPlugin. I do not recommend it here, for the same reason discussed recently w.r.t. foreign GHA in the CD workflow like actions/checkout: the effectiveness of the CD process is only tested if and when you release, so pinning a version would just mean that DB offers updates in PRs which would always pass (assuming no flaky tests or infra) even if they are actually broken.

jglick · 2022-05-13T15:24:50Z

Pinning client repos to @v1 would be fine I guess—we would not expect that to ever be edited, nor would we expect DB to offer a bump to v2.

jglick · 2022-05-13T15:30:31Z

Only makes sense when you have one repo per workflow though.

Either that, or use a orphaned branch per workflow, or include the workflow name in tags.

I tend to agree that using a repo dedicated to this workflow would make more sense from a versioning perspective. Maybe we can just archive this repo and use jenkins-maven-cd-action, as the home of the most salient action in the workflow? In which case the workflow and this third action would share tags?

daniel-beck · 2022-05-13T18:04:40Z

use a orphaned branch per workflow

I expect that may be a barrier to successfully contributing for some people unfamiliar with those; GitHub seems to be pushing "just dump everyone on the default branch" hard. (I may well be wrong though, maintainers seem to handle the weird default orphan branch of private CERT "fork" repos well.)

as the home of the most salient action in the workflow? In which case the workflow and this third action would share tags?

FWIW I considered something like that for jenkins-security-scan and ended up with separate repos for actions and workflows to limit weirdness of version combinations -- which version of each action would be checked out by the workflow? How would I do evolution of the action that requires a corresponding change in the workflow? Having a separate upstream/producer (actions) and downstream/consumer (workflow) seemed more straightforward.

jetersen · 2022-05-13T18:09:58Z

I would keep this repository and have multiple workflows hosted behind main or v1. No need to make it more complicated. Again I would compare shared pipeline library to reusable workflows.

Keeps maintenance simple and separates consumer and producer as noted by @daniel-beck

jglick · 2022-05-13T18:17:08Z

Keeps maintenance simple

Unless and until we find the need to make some incompatible change to the workflow that would affect so many repos we cannot feasibly update them all promptly enough.

Yes we have avoided any such change to buildPlugin()—we have managed to deprecate some things (javaLevel for example) and roll out changes incrementally. So maybe only a theoretical problem.

jetersen · 2022-05-13T18:34:36Z

Theoretical problem, I am pretty sure we can make something that can also solve that.

Use workflow inputs, create another reusable workflow, ask users to stay on v1 while we move on in v2 or they could self host their special workflow.

This solves a immediate problem. I don't want to speculate too much future problems or never problems.

This is simply hosting a group of actions in a workflow and handling updates dependabot noise, if anything the actions are more likely to run into this issue.

jglick · 2022-05-13T18:45:24Z

create another reusable workflow

Indeed that would be the most straightforward approach.

jglick · 2022-05-23T21:51:18Z

Filed jenkinsci/jenkins-infra-test-plugin#20 as a sanity check. I think we can move ahead with this?

.github/workflows/maven-cd.yml

jglick · 2022-05-23T21:53:29Z

.github/workflows/maven-cd.yml

+          output_result: true
+
+      - name: Release Drafter
+        uses: release-drafter/release-drafter@v5


I guess we could actually pin this to a specific version in the shared workflow: we would get DB bumps, which PRs would not test, but after merging we would be sure to run jenkins-infra-test-plugin again to make sure everything still works.

are we talking v5.x.x level of pinning or commit sha pinning? 😅

I meant v5.x.x, I am not that paranoid!

(I did see a tool recently that let you pin actions to hashes and still get them updated.)

jglick · 2022-05-23T21:53:47Z

.github/workflows/maven-cd.yml

+      uses: actions/checkout@v3
+      with:
+        fetch-depth: 0
+
+    - name: Set up JDK 8
+      uses: actions/setup-java@v3


jglick · 2022-05-23T21:54:27Z

README.md

@@ -1,2 +1,3 @@
 # github-reusable-workflows
+


I think it would suffice to edit https://github.com/jenkinsci/.github/blob/1292a5224fbc08abedc30408c14f71e804c95bbb/workflow-templates/cd.yaml#L11-L61

Co-authored-by: Jesse Glick <[email protected]>

daniel-beck · 2022-05-24T08:34:16Z

IIRC both the workflow template as well as the reusable workflow need to declare permissions, otherwise commits from Dependabot will fail the run because the token lacks permissions. See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#changing-github_token-permissions and jenkins-infra/jenkins-security-scan#7 / jenkinsci/.github#75 for when I did this on Jenkins Security Scan workflows.

Mostly cosmetic here because these are unlikely to create releases, but still FYI.

jglick · 2022-05-24T12:23:37Z

jenkinsci/jenkins-infra-test-plugin#20 (comment) and then https://github.com/jenkinsci/workflow-aggregator-plugin/runs/6573189329?check_suite_focus=true#step:4:14 again failed to create a release, due to what I suspect is a race condition. Can we try introducing a delay between Release Drafter and the interesting categories action?

jetersen added 6 commits May 13, 2022 08:00

add editorconfig

9c68fe6

add gitattributes

7673cc4

update README.md

777af98

add dependabot

1ecd53e

add maven-cd workflow

d73593f

Use the same note from original workflow

f01711f

jetersen mentioned this pull request May 13, 2022

Define reusable workflow jenkins-infra/jenkins-maven-cd-action#10

Closed

jetersen commented May 13, 2022

View reviewed changes

.github/workflows/maven-cd.yml Outdated Show resolved Hide resolved

timja reviewed May 13, 2022

View reviewed changes

timja approved these changes May 13, 2022

View reviewed changes

jglick mentioned this pull request May 23, 2022

Use shared CD workflow jenkinsci/jenkins-infra-test-plugin#20

Merged

jglick approved these changes May 23, 2022

View reviewed changes

maven cd

f833484

Co-authored-by: Jesse Glick <[email protected]>

jglick mentioned this pull request Jun 2, 2022

Wait for release metadata to be flushed #2

Closed

jglick mentioned this pull request Jun 10, 2022

Use steps.draft.outputs.body #3

Merged

jetersen merged commit ff51182 into main Jun 13, 2022

jetersen deleted the setup branch June 13, 2022 19:43

jetersen mentioned this pull request Jun 15, 2022

chore: use jenkins infra maven cd reusable workflow jenkinsci/configurationslicing-plugin#117

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

setup maven cd workflow #1

setup maven cd workflow #1

jetersen commented May 13, 2022 •

edited

Loading

jetersen commented May 13, 2022

jetersen May 13, 2022

timja May 13, 2022

timja May 13, 2022

jglick May 13, 2022

jetersen commented May 13, 2022 •

edited

Loading

jetersen commented May 13, 2022

timja May 13, 2022

jglick May 23, 2022

timja commented May 13, 2022

timja commented May 13, 2022

daniel-beck commented May 13, 2022

timja commented May 13, 2022

timja commented May 13, 2022

daniel-beck commented May 13, 2022 •

edited

Loading

jglick commented May 13, 2022

jglick commented May 13, 2022

jglick commented May 13, 2022

daniel-beck commented May 13, 2022 •

edited

Loading

jetersen commented May 13, 2022

jglick commented May 13, 2022

jetersen commented May 13, 2022 •

edited

Loading

jglick commented May 13, 2022

jglick commented May 23, 2022

jglick May 23, 2022

jetersen May 23, 2022

jglick May 23, 2022

jglick May 23, 2022

jglick May 23, 2022

jglick May 23, 2022

daniel-beck commented May 24, 2022 •

edited

Loading

jglick commented May 24, 2022

		@@ -0,0 +1,65 @@
		# Note: additional setup is required, see https://www.jenkins.io/redirect/continuous-delivery-of-plugins

setup maven cd workflow #1

setup maven cd workflow #1

Conversation

jetersen commented May 13, 2022 • edited Loading

jetersen commented May 13, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jetersen commented May 13, 2022 • edited Loading

jetersen commented May 13, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timja commented May 13, 2022

timja commented May 13, 2022

daniel-beck commented May 13, 2022

timja commented May 13, 2022

timja commented May 13, 2022

daniel-beck commented May 13, 2022 • edited Loading

jglick commented May 13, 2022

jglick commented May 13, 2022

jglick commented May 13, 2022

daniel-beck commented May 13, 2022 • edited Loading

jetersen commented May 13, 2022

jglick commented May 13, 2022

jetersen commented May 13, 2022 • edited Loading

jglick commented May 13, 2022

jglick commented May 23, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniel-beck commented May 24, 2022 • edited Loading

jglick commented May 24, 2022

jetersen commented May 13, 2022 •

edited

Loading

jetersen commented May 13, 2022 •

edited

Loading

daniel-beck commented May 13, 2022 •

edited

Loading

daniel-beck commented May 13, 2022 •

edited

Loading

jetersen commented May 13, 2022 •

edited

Loading

daniel-beck commented May 24, 2022 •

edited

Loading