[RelEng] Automate more tasks in promotion/publication jobs #3229
Conversation
| stage('Trigger publication') { | ||
| when { | ||
| //TODO: discuss condition. What about RCs and their sign-off? Does it happen before or after the promotion? | ||
| not { | ||
| environment name: 'DL_TYPE', value: 'R' | ||
| } | ||
| } |
There was a problem hiding this comment.
@MohananRahul is it fine to trigger the immediate publication of promoted builds for milestones and release-candidates? I'm pretty sure fore milestones as they are just promoted as they are without sign-off etc. But I'm not sure about RCs. I.e. do you run the RC promotion after or before sign-off is completed? Looking at old sign-offs and request mails for that, it seems to me that you run the promotion afterwards.
If that's the case, this change should be fine for RC promotions too, shouldn't it?
There was a problem hiding this comment.
Yes, For RC builds, we usually publish the promoted build only after the sign-off is completed. However, for R/GA builds, the promotion is done on Friday (prior to GA), and the publication happens on Wednesday (GA date).
There was a problem hiding this comment.
Yes, For RC builds, we usually publish the promoted build only after the sign-off is completed.
But do you also promote it only after the sign-off? If yes this change is fine and triggering the publication from the promotion-job in case of an RC fits that. But of course it doesn't fit, if you promote before sign-off and then only publish after sign-off.
However since in the past sign-offs were against I-builds, I assume you do both after sign-off, promote and subsequently publish. Is that correct?
However, for R/GA builds, the promotion is done on Friday (prior to GA), and the publication happens on Wednesday (GA date).
Yes that makes sense and is reflected in the current state. I.E. both the promotion and the publication has to be triggered manually at the appropriated times.
| def githubAPI = load "${WORKSPACE}/repository/JenkinsJobs/shared/githubAPI.groovy" | ||
| githubAPI.triggerWorkflow('eclipse-platform/www.eclipse.org-eclipse', 'generateAcknowledgements.yml', [ 'eclipse-version': "${BUILD_MAJOR}.${BUILD_MINOR}" ]) |
There was a problem hiding this comment.
This is intended to trigger the generateAcknowledgements workflow for the news page.
My intention is to have the acknowledgements up-to-date even for milestones/RCs.
The job is capable of updating the acknowledgements for a release if the list already exists (and is just extended) and should just silently fail if no new contributors are added to the list since the same promotion.
All one has to do is check if there is a PR in https://github.com/eclipse-platform/www.eclipse.org-eclipse/pulls, review and submit it.
There was a problem hiding this comment.
I also made sure that the acknowledgment respect the names already existing in the file in case it's re-generated. This will avoid repeated resolution of inconsistent names:
HannesWell
force-pushed
the
automate-more-promotion-tasks
branch
from
1b9711f to
bc905b2
Compare
- Trigger Maven-Central staging for release promotions - Update acknowledgements on each promotion (to have the list up-to-date even for Milestones, etc.) - Trigger publication immediatly for Milestone- and RC-promotions - Only defer for release promotion - Send mail on milestone/RC/release publication - And remove mail template generation from promotion job Extract code to interact with the GitHub-API into a dedicated Groovy-file, which is shared among all using jobs.
HannesWell
force-pushed
the
automate-more-promotion-tasks
branch
from
bc905b2 to
1d1eda7
Compare
|
All my testing was successful and this seams ready to be used. |
2 participants
Automate the following tasks that are current executed manually as part of the build promotion and publication jobs
Extract code to interact with the GitHub-API into a dedicated Groovy-file, which is shared among all using jobs.
@MohananRahul can you please check if the proposed changes are fine?
@elsazac as per updated documentation, with this the promotion to Maven-Central staging should happen automatically during the release promotion (which I assume happens usually at the Friday before the release, on a Wednesday). The only manual task left is then to close the staging repository to perform the final release to Maven-Central.