Skip to content

Run prepareRelease workflow manually and set 'previous-release.baseline' #2576

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Run prepareRelease workflow manually and set 'previous-release.baseline' #2576

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
35 changes: 22 additions & 13 deletions .github/workflows/prepareRelease.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,15 +1,23 @@
name: Prepare Next Release
on:
milestone:
types: [created]
Copy link
Contributor

@laeubi laeubi Nov 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@HannesWell HannesWell Nov 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

workflow_dispatch:
inputs:
nextReleaseName:
description: 'Next release name, e.g.: 2025-03'
required: true
nextReleaseVersion:
description: 'Next release name, e.g.: 4.35'
required: true
baselineRepository:
description: 'Previous release baseline repository, e.g.: 4.34-I-builds/I20241120-1800'
Copy link
Contributor

@laeubi laeubi Nov 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With

and

we can save the update altogether by simply using placeholders.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

required: true

permissions:
contents: read

jobs:
prepare:
runs-on: ubuntu-latest
if: contains(github.event.milestone.description, 'Release')
permissions:
pull-requests: write
contents: write
Expand All @@ -18,10 +26,6 @@ jobs:
uses: stCarolas/setup-maven@d6af6abeda15e98926a57b5aa970a96bb37f97d1 # v5
with:
maven-version: 3.9.9
- id: get-release-name
run: |
name=$(echo ${{ github.event.milestone.due_on }} | cut -d- -f-2)
echo "name=$name" >> $GITHUB_OUTPUT
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
with:
ref: master
Expand All @@ -32,15 +36,20 @@ jobs:
distribution: 'temurin'
cache: maven
- name: Update Main Versions
run: mvn -U -ntp -f eclipse-platform-parent org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=${{ github.event.milestone.title }}.0-SNAPSHOT -Dmodules=../eclipse.platform.releng.prereqs.sdk
run: mvn -U -ntp -f eclipse-platform-parent org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=${{ inputs.nextReleaseVersion }}.0-SNAPSHOT -Dmodules=../eclipse.platform.releng.prereqs.sdk
- name: Update Release Versions
run: mvn -ntp -f eclipse-platform-parent/pom.xml --non-recursive org.eclipse.tycho:tycho-versions-plugin:set-property -Dproperties=releaseVersion,releaseName -DnewReleaseName=${{ steps.get-release-name.outputs.name }} -DnewreleaseVersion=${{ github.event.milestone.title }}
- name: Create Pull Request for Release ${{ github.event.milestone.title }}
run: >-
mvn -ntp -f eclipse-platform-parent/pom.xml --non-recursive org.eclipse.tycho:tycho-versions-plugin:set-property
-Dproperties=releaseVersion,releaseName,previous-release.baseline
-DnewReleaseName=${{ inputs.nextReleaseName }}
-DnewReleaseVersion=${{ inputs.nextReleaseVersion }}
'-DnewPrevious-release.baseline=https://download.eclipse.org/eclipse/updates/${{ inputs.baselineRepository }}'
- name: Create Pull Request for Release ${{ inputs.nextReleaseVersion }}
uses: peter-evans/create-pull-request@5e914681df9dc83aa4e4905692ca88beb2f9e91f # v7.0.5
with:
commit-message: Prepare Release ${{ github.event.milestone.title }}
branch: prepare_R${{ github.event.milestone.title }}
title: Prepare Release ${{ github.event.milestone.title }}
commit-message: Prepare Release ${{ inputs.nextReleaseVersion }}
branch: prepare_R${{ inputs.nextReleaseVersion }}
title: Prepare Release ${{ inputs.nextReleaseVersion }}
body: A new Release Milstone was created, please review the changes and merge if appropriate.
delete-branch: true
milestone: ${{ github.event.milestone.number }}
Expand Down
1 change: 0 additions & 1 deletion Jenkinsfile
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,6 @@ pipeline {
anyOf {
branch 'master'
branch 'R*_maintenance'
branch 'prepare_R*'
}
}
steps {
Expand Down
9 changes: 7 additions & 2 deletions RELEASE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -194,8 +194,14 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
#### **Create new Stream Repos:**
- Run the [Create New Stream Repos](https://ci.eclipse.org/releng/job/Releng/job/newStreamRepos/) job to make an I-builds repo for the next release.

#### **Prepare eclipse-platform-parent pom:**
- Run the [prepareRelease](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/actions/workflows/prepareRelease.yml) GH workflow to create a PR
to prepare the eclipse-platform-parent/pom.xml for for the next release.
- Review and submit the PR created https://github.com/eclipse-platform/eclipse.platform.releng.aggregator.
DO NOT CONTINUE with the next step before this has been completed

#### **Create Git Milestones for the next Release:**
- Milestones in git are created by running the create-milestones job in jenkins, usually after RC1 or RC2. Only specific users can access this job for security reasons. If milestones need to be created and have not please contact @sdawley @sravanlakkimsetti or @laeubi to run it.
- Milestones in git are created by running the `create-milestones` job in jenkins, usually after RC1 or RC2. Only specific users can access this job for security reasons. If milestones need to be created and have not please contact @sdawley @sravanlakkimsetti or @laeubi to run it.

#### **Version Updates:**
- Once the milestones are created (see above) the [Prepare Next Release](https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/actions/workflows/prepareRelease.yml) workflow will run, which will update pom and product versions for the Eclipse repositories and submit pull requests for the changes.
Expand All @@ -209,7 +215,6 @@ The release is scheduled for 10AM EST. Typically the jobs are scheduled beforeha
- Update eclipserun-repo, comparator.repo and eclipse-p2-repo.url in [eclipse-platform-parent/pom.xml](eclipse-platform-parent/pom.xml)
- **Set Previous Version to RC2**
- RC2 becomes the new baseline for the week before the GA release.
- Update previous-release.baseline in [eclipse-platform-parent/pom.xml](eclipse-platform-parent/pom.xml)
- Update the last release build versions in [eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/equinoxp2tests.properties](eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/equinoxp2tests.properties)
- Update the previousReleaseVersion in [eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/label.properties](eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/resources/label.properties)
- Update the name of the copied files in [eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/scripts/getPreviousRelease.sh](eclipse.platform.releng.tychoeclipsebuilder/eclipse-junit-tests/src/main/scripts/getPreviousRelease.sh)
Expand Down
Loading