Staging for version increment automation #449
Conversation
Signed-off-by: pgodithi <[email protected]>
Signed-off-by: pgodithi <[email protected]>
|
Renaming to task updateVersion following opensearch-project/opensearch-plugin-template-java#32. |
Codecov Report
@@ Coverage Diff @@
## main #449 +/- ##
============================================
- Coverage 74.63% 73.31% -1.32%
+ Complexity 1006 986 -20
============================================
Files 141 141
Lines 4565 4565
Branches 504 504
============================================
- Hits 3407 3347 -60
- Misses 841 904 +63
+ Partials 317 314 -3
Continue to review full report at Codecov.
|
|
Security tests are failing. Security plugin has to updated before this PR can be merged. |
| println "Setting version to ${newVersion}." | ||
| // String tokenization to support -SNAPSHOT | ||
| ant.replaceregexp(file:'build.gradle', match: '"opensearch.version", "\\d.*"', replace: '"opensearch.version", "' + newVersion.tokenize('-')[0] + '-SNAPSHOT"', flags:'g', byline:true) |
There was a problem hiding this comment.
We also have BWC tests where we test the upgrade with previous major version(i.e. opensearch_previous_version).
This method should also upgrade the opensearch_previous_version if there is a major version bump for opensearch.version.
There was a problem hiding this comment.
Hey @ankitkala Once the cross-cluster-replication is aligned to core repo branching (Related issue), since main will be the next major version, so do you think it has to be part of version increment?
@bbarani
There was a problem hiding this comment.
@prudhvigodithi Regarding the migration to core, we're yet to figure out how to completely move to core. Most likely, we'll still require a separate plugin (to start with) and eventually would move completely to core.
But anyways, the BWC tests are not specific to CCR plugin. Don't have to necessarily do in this PR but still we should sort that part out. What do you think?
There was a problem hiding this comment.
Hey @ankitkala are we on the same page? :), I mean CCR to align with core branching strategy, CCR can still be a separate plugin but uses same as core branching strategy, main will be the next major version, <major version>.x branch (example 2.x) will be next minor version and 2.1 or 2.2 branches will be for hotfix/patch versions.
If we follow this way opensearch_previous_version can be maintained as per branch for BWC tests alone.
There was a problem hiding this comment.
My bad. Please ignore my comment around "move to core".
I got what you mean with the branching strategy. Basically we only modify the opensearch_previous_version when we move to a new major version.
But if we're planning to use this automation for major version bump as well, then we should be handling this IMHO. Otherwise its just one more thing plugin owners need to remember. As an alternative, if you want to keep that as a checklist item in every new major release, that is fine as well.
Thoughts?
There was a problem hiding this comment.
Added a tracking issue for this: opensearch-project/opensearch-build#2373
|
@ankitkala Can you please review this PR soon? |
* Version increment automation Signed-off-by: pgodithi <[email protected]> * Version increment automation: task rename updateVersion Signed-off-by: pgodithi <[email protected]> (cherry picked from commit db5029a)
@bbarani I've merged the PR. I've opened an issue for tracking BWC related changes: opensearch-project/opensearch-build#2373 |
Signed-off-by: pgodithi [email protected]
Description
This is the staging PR for to execute workflows that auto raise the version increment PR's
Example: prudhvigodithi#1
Issues Resolved
Part of: opensearch-project/opensearch-build#1375
From solution: opensearch-project/opensearch-build#1375 (comment)
Related issue: #443
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.