Run prepareRelease workflow manually and set 'previous-release.baseline' #2576
Conversation
| @@ -1,15 +1,23 @@ | |||
| name: Prepare Next Release | |||
| on: | |||
| milestone: | |||
| types: [created] | |||
There was a problem hiding this comment.
I don't see how running the workflow manually helps in any way, the whole purpose of this is to automate the process, e.g. exactly this manually run was performed before (but not with an action).
If one want some "timed" process, then better the process to create the milestones should be adjusted, for example one can create first the milestones in the aggregator, then this workflow runs and this can then trigger the creation of the milestones in other repositories.
If one wants, it would even work to create the (release) milestone manually in this repository using Github UI first.
There was a problem hiding this comment.
If one want some "timed" process, then better the process to create the milestones should be adjusted, for example one can create first the milestones in the aggregator, then this workflow runs and this can then trigger the creation of the milestones in other repositories.
It is to better time the action plus to set the baseline earlier, which saves all the manual version bumps!
I the job that creates the milestones is hidden for me, but I assume it currently creates the milestones for all repos at once. I don't see how it is simple to enter all the milestone data twice with all the dates for M1, M2, M3, RC1, RC1 and GA plus the names instead of running one GH workflow with three inputs in advance.
If one wants, it would even work to create the (release) milestone manually in this repository using Github UI first.
That would again be a manual process that has also three input parameters and is more fragile. And the baseline would have to be set manually again. So it would actually be more complicated than this proposal.
On the long run I think the goal should be any ways that all the release preparation work is done or triggered in one job that considers most of the tedious and fixed steps and has also all the required timings/orders recorded (e.g. waits until a specific PR is submitted if necessary). So I see this as an intermediate solution anyways.
Depending where such a job will reside, Jenkins or GH (and the the most inpact on the answer has probably the question were we want to store tokens that have access to all repos), this job might also be called from a Jenkins job using the GH REST API.
| description: 'Next release name, e.g.: 4.35' | ||
| required: true | ||
| baselineRepository: | ||
| description: 'Previous release baseline repository, e.g.: 4.34-I-builds/I20241120-1800' |
There was a problem hiding this comment.
With
and
we can save the update altogether by simply using placeholders.
There was a problem hiding this comment.
I don't see how this would work in the peride after RC1 and GA, the one we are currently in.
It used to be https://download.eclipse.org/eclipse/updates/4.33/R-4.33-202409030240/
now it is https://download.eclipse.org/eclipse/updates/4.34-I-builds/I20241120-1800/
and it will be https://download.eclipse.org/eclipse/updates/4.33/R-4.33-2024XXXXXXXX.
Besides the transition period between RC2 and GA, #2575 misses the date component.
As described in #2550 (comment) ff running the
prepareReleaseworkflow and submitting the automatically created changes in theeclipse-platform-parent/pom.xmlbefore the milestones are created and thus theupdateReleaseworkflow is triggered in all SDK repos, will ensure that in the parent-version update PR created in the other repos the project versions can already be bumped by the automatic version bump workflow. With that all release preparation changes necessary in the other repos are created automatically and one just has to review the PRs and submit it.