[MDEPLOY-267] add parameters to deploy or not non snapshots or release (-DskipRelease or -DskipSnapshot)

[jira-importer]

Olivier Lamy opened MDEPLOY-267 and commented

maven-release-plugin creates a commit where the pom is not a SNAPSHOT version: if CI system is configured to build on every commit and to deploy the artifacts on every build (with the intent in general to deploy updated SNAPSHOTs on every commit), the CI will deploy the non-SNAPSHOT that has already been deployed by the user who launched mvn release:perform, then it will generate an error (trying to override existing release artifact) and/or create new staging repository and/or override artifacts partially (if repository not configured to block overrides)

we can add a new parameter -DdeployOnlySnaphots=true/false: it will be false per default for normal use, but can be configured to true in users' CI system.

---

Remote Links:

• GitHub Pull Request #10
  

0 votes, 5 watchers

[jira-importer]

Robert Scholte commented

Hmm, feels like a hack, because you should require the same for the maven-install-plugin. Just for the context: is the CI Jenkins pipelines?

[jira-importer]

Olivier Lamy commented

 If you use a pattern such releasing from master because of the maven-release-plugin master can have a non SNAPSHOT version.

why a hack? how do you want to prevent deploying non SNAPSHOT without having build failure and you cannot do anything to prevent this.

I have less concern install/local repo CI builds can easily cleanup local repo and now with cloud agent they mostly start with an empty repo.

 

[jira-importer]

Robert Scholte commented

because of the maven-release-plugin master can have a non SNAPSHOT version

You mean that the maven-release-plugin itself is a SNAPSHOT and you to release another project with this?

[jira-importer]

Olivier Lamy commented

sorry for the typo :)

I mean release plugin leave (temporary or even longer in case of issue) the project in non SNAPSHOT version in the scm.

 

 

[jira-importer]

Robert Scholte commented

This is about a ratrace condition where 2 "branches" both try to deploy a non-SNAPSHOT, because the maven-release-plugin first pushes the master/develop branch, and ater that the tag. In such case you'd always want the tag to win.
I've hit a similar situation with jgitflow and managed to fix this in the pipeline by saying: only build if it is the master branch (with jgitflow this is where are all non-snapshots are merged too) or the project is a SNAPSHOT.
Stephen Connolly what's your idea here?

[jira-importer]

Stephen Connolly commented

So IIUC the issue here is where you are using the release plugin and building every commit.

Thus when you build the release commit in between where the mainline has SNAPSHOTS you try to deploy, but without the correct deploy goals and may miss deployment artifact’s as well as potentially fail if you collide with artifacts from the actual release build.

I agree that is problematic, But it’s problematic because of choices made by the user that Maven cannot know about.

I’m now 2+ years following a pattern where every commit on master is a release build with the Maven release plugin... but we never push the master branch back, rather throw it away... we push the tag back though... and this is awesome... no longer do we have diffs on the master branch... with that choice of how to do CI this is not an issue

Similarly, it would be trivial to write a “guard” plugin that sets a system property if the current version is not a SNAPSHOT. Thus you could run mvn guard:check deploy from the CI server and have guard:check set the skip properties for install and deploy plugins...

OTOH if we we want to add config here as this ticket is suggesting then we should be complete and add a property to skip deploying SNAPSHOTS as well as one to skip releases... and add same properties to the install plugin

[jira-importer]

Robert Scholte commented

I've found another reason why the parameter approach is a codesmell: it will be exposed as configurable parameter, however you should never configure it in your pom. Based on that, it makes more sense to me to have it as a maven extension.

[jira-importer]

Stephen Connolly commented

Not true. I might want to configure my release profile to have it off in order to ensure that all release deployments are made through the release plugin.

[jira-importer]

Stephen Connolly commented

Note, I am not arguing for this property... as it increases the number of configuration flags that have inter-connected logic and thus makes things harder to reason on... rather I am rejecting your reasoning for rejecting it 🤣

[jira-importer]

Robert Scholte commented

Ah, the evil profiles :)

[jira-importer]

Herve Boutemy commented

disclaimer: I don't have yet an opinion if this should be done or not, just trying to understand and make the best possible proposal before deciding

I rewrote the issue description with Stephen's first comment as input, because this is the comment that made me understand what is tried to be achieved = avoid double release artifacts deploy (one from the release process, one from the CI)

one thing that lost me initially is the name of the parameter: -DdeployOnlySnaphots=true/false

given existing parameters, I would propose something like -DskipRelease=true/false

then this parameter could be set to "true" on normal builds, and overridden to "false" in the release profile: as described by Stephen, this would "ensure that all release deployments are made through the release plugin", which seems nice (not related to CI condition)

[jira-importer]

Herve Boutemy commented

Ah, the evil profiles

is release profile evil?

are profiles evil? AFAIK, magic activation may be an issue, but profiles are necessary for a minimum of flexibility

I hate naming something "evil" to just kill discussion

[jira-importer]

Robert Scholte commented

The profiles assume that the deployments are done on the local system (so they can be activated). However, if they are pushed and the CI server is responsible for pushing, you can still have the 2 branches battling for the deployment.
I would expect that one of the branches shouldn't be built at all and not just disabling installing/deploying. One of the next pushes would be another SNAPSHOT version, that's again the one to build.

[jira-importer]

Herve Boutemy commented

the idea to configure this parameter in release profile don't assume anything on where the release process is run: the release process is the only process configured to deploy artifact

this removes the CI-specific configuration, which I didn't feel well

[jira-importer]

Stephen Connolly commented

I prefer the name skipReleases which should also have it’s mirror: skipSnapshots