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

Release to Maven Central via AppVeyor #24

Closed
dblock opened this issue Jul 12, 2016 · 4 comments
Closed

Release to Maven Central via AppVeyor #24

dblock opened this issue Jul 12, 2016 · 4 comments
Assignees

Comments

@dblock
Copy link
Owner

dblock commented Jul 12, 2016

I am too thick to understand why we need both those files :)

@claudiow
Copy link
Contributor

Lets see if I can explain this. It is not a bug it is a feature ;).

If you agree with my vision that the releases should be built in the CI server and only if you agree with this, what follows will make sense.

First of all the name is misleading I will rename appveyor-mvn-conversion.yml to appveyor-mvn-release.yml. The name comes from me separating what was ready to merge from what I was testing in my own instance of AppVeyor.

We want 2 builds in AppVeyor one that is triggered every time that the code changes and deploys the SNAPSHOT and one that is triggered manually whenever all coding is done and we want to perform a release to Maven Central.

The two builds perform different tasks (The notes are verbatim form Maven's site):
appveyor.yml runs atomatically performing mvn clean deploy this builds the jars, signs them and deploys them to https://oss.sonatype.org/content/repositories/snapshots you can see this here

appveyor-mvn-conversion.yml runs manually and uses the maven-release-plugin here is the sequence:

mvn release:prepare:

  1. Check that there are no uncommitted changes in the sources
  2. Check that there are no SNAPSHOT dependencies
  3. Change the version in the POMs from x-SNAPSHOT to a new version (you will be prompted for the versions to use)
  4. Transform the SCM information in the POM to include the final destination of the tag
  5. Run the project tests against the modified POMs to confirm everything is in working order
  6. Commit the modified POMs
  7. Tag the code in the SCM with a version name (this will be prompted for)
  8. Bump the version in the POMs to a new value y-SNAPSHOT (these values will also be prompted for)
  9. Commit the modified POMs

mvn release:perform:

  1. Checkout from an SCM URL with optional tag
  2. Run the predefined Maven goals to release the project (by default, deploy site-deploy)

If there is a failure in the build it will undo everything by running mvn release:rollback:

  1. All project POMs are reverted back to their pre-release state locally, and also in the SCM if the previous release command was able to successfully make changes in the SCM to the POMs. This is done by using the backup files created during release:prepare.
  2. The created branch/tag in SCM for the release is removed. Note: This is not yet implemented so you will need to manually remove the branch/tag from your SCM.

You will see this as the appveyor-mvn-release.yml evolves during the testing.

@claudiow
Copy link
Contributor

claudiow commented Jul 12, 2016

If you agree that we want to build the releases in the CI server this is why you can't have all the configuration in one file. This blog post is what I'm basing my approach on.

@dblock dblock changed the title appveyor-mvn-conversion.yml duplicates appveyor.yml Release to Maven Central via AppVeyor Jul 13, 2016
@dblock
Copy link
Owner Author

dblock commented Jul 13, 2016

I agree that we want to build releases via CI, that's a great goal to have. I've renamed this issue to Release to Maven Central via AppVeyor, to track all of the above.

@dblock
Copy link
Owner Author

dblock commented Apr 17, 2022

Closing in favor of #53

@dblock dblock closed this as completed Apr 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants