#1594: Implement release commandlet#2023
Conversation
13ab4c6 to
d28f993
Compare
d491923 to
0547ac4
Compare
78e6ead to
d9c6911
Compare
Coverage Report for CI Build 29108746467Coverage decreased (-0.03%) to 72.199%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions55 previously-covered lines in 3 files lost coverage.
Coverage Stats💛 - Coveralls |
hohwille
left a comment
There was a problem hiding this comment.
@laert-ll thank you for your PR. Great work 👍
Since this was somehow stuck in team-review without a reviewer assigned and I came across, I took the fast lane and moved it to the final review.
Regarding my reivew comments you did nothing wrong. I just want to improve the design for better SoC, reuse and maintainability.
| private static final String REVISION_FLAG = "-Drevision="; | ||
|
|
||
| private static final String DEFAULT_MVN_RELEASE_OPTS = "clean deploy -Dchangelist= -Pdeploy"; |
There was a problem hiding this comment.
Can you please follow SoC and delegate the build to the according commandlet (here Mvn).
I would create an interface BuildTool that has a methods like
buildAndDeploy()getProjectVersion(Path projectPath)setProjectVersion(Path projectPath, VersionIdentifier version)
and implement this interface inMvn(we can later also implement it inGralde,Npm,Yarnso we support doing releases with them without the need ti change theReleaseCommandlet).
Therefore have a look how our BuildCommandlet is implemented:
It can already automatically check if there is a pom.xml file and then will invoke mvn and if it finds a build.gradle it will call gradle and in case of package.json it will use npm or yarn depending on the presence of a yarn.lock or not.
However, the BuildCommandlet itself has absolutely no knowledge about pom.xml, package.json, etc. nor of the default build option variables.
We should reuse the same infrastructure and design this commandlet in a similar way.
| private String getNextVersion(String version) { | ||
|
|
||
| int lastDot = version.lastIndexOf('.'); | ||
| String prefix = version.substring(0, lastDot + 1); | ||
| String lastSegment = version.substring(lastDot + 1); | ||
| String incrementedSegment = String.valueOf(Long.parseLong(lastSegment) + 1); | ||
| incrementedSegment = "0".repeat(lastSegment.length() - incrementedSegment.length()) + incrementedSegment; | ||
| return prefix + incrementedSegment; | ||
| } |
There was a problem hiding this comment.
Instead of bash-hacking we now have Java and can avoid such "string-fiddling".
Please reuse what we already have implemented:
IDEasy/cli/src/main/java/com/devonfw/tools/ide/version/VersionIdentifier.java
Lines 257 to 265 in 365f379
| cmd.quarkus=Tool commandlet for Quarkus (framework for cloud-native apps). | ||
| cmd.quarkus.detail=Quarkus is a Kubernetes-native Java framework for building cloud-native applications. Detailed documentation can be found at https://quarkus.io/ | ||
| cmd.release=Performs a release of the project in your current working directory. | ||
| cmd.release.detail=The `release` commandlet automates a release of the project in your current working directory. It ensures there are no uncommitted changes, warns if you work on a fork, determines the current version of your project and derives the release version and the next development (SNAPSHOT) version for you to confirm. It then sets the release version, commits and tags it via git (as `release/«version»`), builds and deploys the project, sets the next development version, commits, and (after your confirmation) pushes the changes and the tag. Build and deploy options can be configured via the variable `MVN_RELEASE_OPTS` (default `clean deploy -Dchangelist= -Pdeploy`). You may also supply additional arguments as `ide release «args»` that will be passed to the maven build command. |
There was a problem hiding this comment.
It is great that you give such detailed help here.
However, for maintenance this is IMHO too detailed.
I would recommend to move the MVN_RELEASE_OPTS to the variables.adoc and keep the maven specific part out of here. In the last sentence you can replace maven build command with underlying build command (e.g. mvn).
| @Override | ||
| public void commit(Path repository, String message) { | ||
|
|
||
| runGitCommand(repository, "commit", "-a", "-m", message); |
There was a problem hiding this comment.
I do not know what might come in the future but adding -a here is dangerous.
Typically you only want to commit what has already been added.
I would recommend to add a boolean option addAll so you do not also need to implement an add method here.
In the interface you may keep a variant without the option that delegates by passing false to addAll.
In your code you can then call it with true.
| @Override | ||
| public void push(Path repository) { | ||
|
|
||
| runGitCommand(repository, "push", "--follow-tags"); |
There was a problem hiding this comment.
--follow-tags should better also be optional.
| public java.util.List<String> retrieveGitRemotes(Path repository) { | ||
|
|
||
| return java.util.Collections.emptyList(); | ||
| } |
There was a problem hiding this comment.
| public java.util.List<String> retrieveGitRemotes(Path repository) { | |
| return java.util.Collections.emptyList(); | |
| } | |
| public List<String> retrieveGitRemotes(Path repository) { | |
| return Collections.emptyList(); | |
| } |
| * https://github.com/devonfw/IDEasy/issues/797[#797]: Fix VSCode install on macOS | ||
| * https://github.com/devonfw/IDEasy/issues/1956[#1956]: Merging MAVEN_ARGS buggy | ||
| * https://github.com/devonfw/IDEasy/issues/1978[#1978]: Enhanced the quality status documentation | ||
| * https://github.com/devonfw/IDEasy/issues/1594[#1594]: Add release commandlet |
| @@ -0,0 +1,2 @@ | |||
| #!/bin/bash | |||
| echo java $* | |||
There was a problem hiding this comment.
For simplicity, you could also remove dependencies.json since the goal of this test is to test ReleaseCommandlet and not Mvn so we do not have to include java at all.
Esp. we do not need a java.cmd command that is used in favour of java but only in Windows.
A kind of goal for test projects is to keep them as minimal as possible as long as they are realistic to test what the commandlet should do.
This PR fixes #1594
Implemented changes:
Testing instructions
Checklist for this PR
Make sure everything is checked before merging this PR. For further info please also see
our DoD.
mvn clean testlocally all tests pass and build is successful#«issue-id»: «brief summary»(e.g.#921: fixed setup.bat). If no issue ID exists, title only.In Progressand assigned to you or there is no issue (might happen for very small PRs)with
internal