Skip to content
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

mvn gitflow:release - Not installing release-version #13

Closed
DemonicTutor opened this issue Apr 27, 2016 · 6 comments
Closed

mvn gitflow:release - Not installing release-version #13

DemonicTutor opened this issue Apr 27, 2016 · 6 comments
Assignees

Comments

@DemonicTutor
Copy link

DemonicTutor commented Apr 27, 2016

when running mvn gitflow:release i would expect the RELEASE to be installed in my local maven repository.

e.g.:
%MVN_REPO%/my/group/myartifact/1.0.0-SNAPSHOT/myartifact-1.0.0-SNAPSHOT.war
%MVN_REPO%/my/group/myartifact/1.0.0/myartifact-1.0.0.war

But this does not happen.. only the previous and next SNAPSHOT's are there.

my config:

<plugin>
        <groupId>com.amashchenko.maven.plugin</groupId>
        <artifactId>gitflow-maven-plugin</artifactId>
        <configuration>
          <mvnExecutable>mvn</mvnExecutable>
          <gitExecutable>git</gitExecutable>

          <installProject>true</installProject>
          <verbose>true</verbose>

          <skipTag>false</skipTag>
          <keepBranch>false</keepBranch>
          <skipFeatureVersion>false</skipFeatureVersion>
          <skipTestProject>false</skipTestProject>
          <allowSnapshots>false</allowSnapshots>

          <gitFlowConfig>
            <productionBranch>master</productionBranch>
            <developmentBranch>develop</developmentBranch>
            <featureBranchPrefix>feature/</featureBranchPrefix>
            <releaseBranchPrefix>release/</releaseBranchPrefix>
            <hotfixBranchPrefix>hotfix/</hotfixBranchPrefix>
            <supportBranchPrefix>support/</supportBranchPrefix>
            <versionTagPrefix></versionTagPrefix>
          </gitFlowConfig>
          <commitMessages>
            <featureStartMessage>updating versions for feature branch</featureStartMessage>
            <featureFinishMessage>updating versions for development branch</featureFinishMessage>

            <hotfixStartMessage>updating versions for hotfix</hotfixStartMessage>
            <hotfixFinishMessage>updating for next development version</hotfixFinishMessage>

            <releaseStartMessage>release build ${project.version}</releaseStartMessage>
            <releaseFinishMessage>updating for next development version</releaseFinishMessage>

            <tagHotfixMessage>tagging hotfix</tagHotfixMessage>
            <tagReleaseMessage>tagging release</tagReleaseMessage>
          </commitMessages>
        </configuration>
      </plugin>
@aleksandr-m
Copy link
Owner

What is your use case for that? Why do you need a release version to be installed locally?

Unrelated: You do know that you don't have to put all plugin configuration option into pom, don't you?

@DemonicTutor
Copy link
Author

DemonicTutor commented Apr 28, 2016

We are not using a maven repo (artifactory / nexus) and i do not want to deploy to a server from maven.

After running the release i am SCPing the deployable artifacts (WAR, SQL-Scripts, properties) to a other site and runnig a automated deployment from there.

Currently after running mvn gitflow:release i have to checkout master and run mvn clean install.

Additionally i don't see a reason why you would not want to have the artifact installed which you just tried to create - probably unnecessary if most people run hudson and nexus but it still makes more sense to install locally too.

Edit:
After thinking about it a bit more this is what would make the most sense to me:

When running mvn gitflow:release i would like the plugin to do:

pre-release

Happens before any modifications.

  • check GIT
    • clean workspace?
    • are submodules up-to-date and tracking their master ? (don't know if possible)
    • correct branch beeing run from?

develop should be the only one to be merged to master (already configurable what they are really called)

  • execute mvn verify

Before upgrading the Version personally i would want to run findbugs:check, pmd:check, checkstyle:check - it doesn't make sense to go for a release without this and they are not as costly as running the full Unit/Integration-Test cycle.

The possiblity to configure the goals and profiles like

<preRelease>verify jacoco:test -PpreRelease</preRelease>

would be awesome.

release

Upgrade version and commit

  • execute * mvn clean install deploy*

The possiblity to configure the goals and profiles like

<release>clean install site:site -Pclean-build-frontend,release</release>

would be awesome.

post-release

Upgraded to next SNAPSHOT

  • execute mvn install

The possiblity to configure the goals and profiles like

<postRelease>install -DskipTests=true -DskipPMD=true, -DskipFindbugs=true, -DskipCheckstyle=true -PpostRelease</postRelease>

would be awesome.


my current workflow

Right now i am basically doing this manually by:

# Assume we are already in the release-process - CodeFreeze / Feature-Test / getting everything merges / Integration-Test / System-Test / Regression-Test already happened
git checkout develop
git status
git pull / push
git submodule update --remote
# manual check if commit is the merge-commit to master of the frontend-submodule
# clean build including frontend to have code-quality-checks and unit-tests run
mvn clean install -Pclean-build-frontend
# run release
mvn gitflow:release
# develop-branch is usually fine - push it
git push
git checkout master
# now i dont want the -no-ff merge
# git reset hard previous commit on master (previous release)
git merge develop
# delete the created tag / create new tag
git push
git checkout <NEW-TAG>
# now i have to run the build to get my actual artifact ill be using ... also i have to run site:site
mvn clean install site:site -Pclean-build-frontend
# Copy artifact to remote-site
# Start automated deployment
# check site-build/deployment
git checkout develop
# finally the release is done

now this could be much shorter:

git checkout develop
git status
git pull / push
git submodule update --remote
mvn gitflow:release
git push
# Copy artifact to remote-site
# Start automated deployment
# check site-build/deployment

Not sure if this is 100% accurate.. im not at work right now :)

@DemonicTutor
Copy link
Author

Unrelated: You do know that you don't have to put all plugin configuration option into pom, don't you?

Yeah... that's just some kind of personal spleen with plugins i just started using... don't want to lookup all the options all the time but have them right there.

@aleksandr-m
Copy link
Owner

Installing next development version locally makes sense since most probably you're going to work with that. Deploying released artifact makes more sense than installing it locally, but that is another story. :)

Allowing to set profiles should be enough to execute configured plugins for that profile. (E.g. to install released artifact.)

Thanks for sharing.

@aleksandr-m
Copy link
Owner

aleksandr-m commented Apr 11, 2017

@DemonicTutor Initial commit to allow to run additional Maven goals is here.
Please test and review.

@aleksandr-m
Copy link
Owner

Implemented in 9e57bb0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants