-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CD guide for releasing plugins #4341
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Content-wise looks good; unsure whether we want to recommend this as the default just yet (increases pressure on infra team a lot if adopted).
Does this make sense to add? It means that if RPU updating breaks you have a workaround to release still via github. and it's already documented how to release if ci.jenkins.io is down in the fallback. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for driving this!
|
||
=== Further troubleshooting help | ||
|
||
If none of the provided solutions help, send an email to the link:/mailing-lists[Jenkins developers mailing list] and explain what you did, and how it failed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or better to file an INFRA
ticket?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well, it'll get sorted a lot quicker in IRC...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I agree that it will be faster to ask for help on IRC, creating a ticket will be useful for documentation purposes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
better? assuming you meant the lines above, or was i mis-reading =/
issues with releasing have normally gone to the developer mailing list, (unless it's obviously an infra issue)
|
||
For a regular component whose version number is not that meaningful: | ||
|
||
[source,diff] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we should create a new goal like incrementalify
(or option to that goal) to do this sort of edit. And/or a flag in archetypes
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes that would be great, I was thinking about this at least in context of the IRC bot, is there any reason not to automatically opt new plugins in to the cd.enabled flag? i.e. don't bother adding a flag to Jira in the hosting issue.
Also do we need a new flag in archetypes or can we assume plugins use the is hosted on jenkinsci flag should use this setup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any reason not to automatically opt new plugins in to the cd.enabled flag?
That would be a question for @daniel-beck probably.
can we assume plugins us[ing] the is hosted on jenkinsci flag should use this setup?
We should probably get some more diverse adoption before making this the default for new plugins.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there any reason not to automatically opt new plugins in to the cd.enabled flag?
Assuming this is asking "why not set this even if unused":
- This effectively changes the permission model; anyone with commit access to the repo can deploy (even if jumping through hoops to get the token). Right now folks can add whoever they want to GH as committers and it doesn't affect the bits we distribute;
cd.enabled
changes this. - Every repo adds about 1-2 seconds to the execution time of the RPU run.
Co-authored-by: Jesse Glick <[email protected]>
Co-authored-by: Jesse Glick <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should add the preview state disclaimer before merging. The rest of the comments are non-blocking suggestions
- url: /jep/229 | ||
title: 'JEP-229: Continuous Delivery of Jenkins Components and Plugins' | ||
--- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
WARNING: Continuous Delivery of Jenkins Components and Plugin (jep:229[]) is currently in preview. | |
See the referenced Jenkins enhancement proposal and references in it to see the current state. | |
Any feedback from early adopters will be appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where is it marked as preview?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is not. Should be reworded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: Continuous Delivery of Jenkins Components and Plugin (jep:229[]) is relatively new. | |
Any feedback from early adopters will be appreciated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roadmap-wise, an initiative is in preview until the respective JEP is formally accepted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/jenkinsci/jep/tree/master/jep/14 does not state that as far as I can tell.
I don't think this discussion is for this pull request.
Nothing I can see anywhere states that this requires a preview disclaimer, I think the current disclaimer is appropriate.
Please take the bits about github actions long term to the mailing list as it doesn't belong in this PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FTR the public roadmap had a preview disclaimer until formal publishing and JEP acceptance approval by the Jenkins Governance Meeting and then by the BDFL delegate. See #3527 for the pull request which removed the disclaimer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That may be true but does not appear to be required?
references: | ||
- url: ../releasing-cd | ||
title: Through GitHub | ||
- url: ../releasing-manually |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would keep manual releases here, but no strong opinion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is keeping the manual release guide content here until JEP-229 is accepted. I am not blocking the PR by this comment
Co-authored-by: Oleg Nenashev <[email protected]>
- url: /jep/229 | ||
title: 'JEP-229: Continuous Delivery of Jenkins Components and Plugins' | ||
--- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE: Continuous Delivery of Jenkins Components and Plugin (jep:229[]) is relatively new. | |
Any feedback from early adopters will be appreciated. |
Co-authored-by: Jesse Glick <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is relatively new" IMHO does not explain the current state. IMHO we have not yet reached a consensus whether we want to keep using GitHub actions in longer term
- url: /jep/229 | ||
title: 'JEP-229: Continuous Delivery of Jenkins Components and Plugins' | ||
--- | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Roadmap-wise, an initiative is in preview until the respective JEP is formally accepted
AFAICT there is consensus: Other than you, I've not seen anyone involved even tangentially who thinks this is a bad idea. And nobody has presented a plan how to make this work using Jenkins while the infra team is already under water. |
…even assuming availability of someone to work on it, since any hypothetical job on a secured server would need to be given limited permission not just to Artifactory but also to GitHub in order to update releases and invoke Release Drafter, introducing significant permission management issues. Could add more to https://github.com/jenkinsci/jep/tree/master/jep/229#github-actions as needed but I do not foresee this decision being revisited. |
@oleg-nenashev ping. If no response in a couple of days I'll merge this. |
no response, request for change rejected
Mostly an import of content from https://github.com/jenkinsci/incrementals-tools