-
Notifications
You must be signed in to change notification settings - Fork 79
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
Use placeholder to define the integration build repository #2574
base: master
Are you sure you want to change the base?
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.
Seems fine. But I don't have in-depth knowledge about the details.
Sorry, I don't really understand the question? |
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.
Overall looks good, just the question about releaseVersion containing micro version .
@@ -77,9 +78,9 @@ | |||
'eclipiserun-repo' repository, such as for computing .api-descriptions and | |||
generating API Tools reports. | |||
--> | |||
<eclipserun-repo>https://download.eclipse.org/eclipse/updates/4.34-I-builds/</eclipserun-repo> | |||
<eclipserun-repo>https://download.eclipse.org/eclipse/updates/${releaseVersion}-${buildType}-builds/</eclipserun-repo> |
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.
Should releaseVersion be 4.35 (not 4.35.0) for this to work? There shouldn't be https://download.eclipse.org/eclipse/updates/4.35.0-I-builds/
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, good point.
Currently we have https://download.eclipse.org/eclipse/updates/4.34-I-builds and the ibuilds seem to push their content there but:
So what would be required is that unless "point 4" has happened there already is https://download.eclipse.org/eclipse/updates/4.35-I-builds but simply points to https://download.eclipse.org/eclipse/updates/4.34-I-builds So we can use the "new" URL already even though it has not yet the content (and just is an alias).
Yes that's because I'm using an outdated version here, I'll rebase this on master. |
Actually the both properties 'releaseNumberSDK' and 'releaseNumberPlatform' are always the same and even if the comment mentions they might be different at some time it is better to unify them until then. Because of this there is now a new 'releaseVersion' defined as a single property. Use placeholder to define the integration build repository Currently we use fixed strings that regularly needs to be updated, but the contents could actually be computed automatically. This replace fixed strings with using properties making it needless to change them all the time.
57fc4ce
to
87b0ca1
Compare
I see. The empty state of https://download.eclipse.org/eclipse/updates/4.35-I-builds is indeed rather inconvenient. Unfortunately I have no knowledge of how these composites are maintain/managed. 😞 |
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.
To me this looks good as well, during the release process it should just be made sure that upon creation of the new I-build repo should get the linked to the latest RC as mentioned already.
At least the repository already exists a.t.m. but is empty:
https://download.eclipse.org/eclipse/updates/4.35-I-builds/
Their creation is tracked in #2564
I see. The empty state of https://download.eclipse.org/eclipse/updates/4.35-I-builds is indeed rather inconvenient. Unfortunately I have no knowledge of how these composites are maintain/managed. 😞
#2564 mentions the Jenkins job https://ci.eclipse.org/releng/job/Releng/job/newStreamRepos/.
I think in general all eclipse
(-SDK) repos are managed through the Jenkins jobs in https://ci.eclipse.org/releng/job/Releng/, which are defined in
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/5bddc6c2de3374aed50318b550b71222f2963f15/JenkinsJobs/Releng
From the definition of the newStreamRepos
job I think after the https://download.eclipse.org/eclipse/updates/template_repo/ has been copied we should 'simply' do the same as the I-build does when it adds a new I-build sub-repo, just linking the latest RC. Or the new stream repos should already be created before RC2 and adding an RC should be part of the RC2+x process in order to always use the latest RC.
The commit message does not match the content anymore. |
Currently we use fixed strings that regularly needs to be updated, but
the contents could actually be computed automatically.
This replace fixed strings with using properties making it needless to
change them all the time. (this also includes the changes from #2573)
This would need just one little adjustment in the process, the next stream I-Build repository must point to the previous stream until the first I-Build happens.
So what do you think? @merks can you tell how much effort it would be regarding the inclusion of the previous stream? I'm not sure how the exact process is with the ibuild repos.