Use CI to publish releases

[mojavelinux]

We should consider using Travis CI to publish a release. We could even design it so that Travis creates the tag itself triggered by keywords in the commit statement. The most we can automate, the more time we have to enough the release :)

See the following post for some tips:

http://mnmlst-dvlpr.blogspot.de/2014/12/my-lightweight-release-process.html

[LightGuard]

This would be great!

On Thu, Dec 25, 2014 at 3:24 AM, Dan Allen notifications@github.com wrote:

We should consider using Travis CI to publish a release. We could even
design it so that Travis creates the tag itself triggered by keywords in
the commit statement. The most we can automate, the more time we have to
enough the release :)

See the following post for some tips:

http://mnmlst-dvlpr.blogspot.de/2014/12/my-lightweight-release-process.html

—
Reply to this email directly or view it on GitHub
#141.

Jason Porter
http://en.gravatar.com/lightguardjp

[lordofthejars]

Yes we Can start with maven plugin and then use it in asciidoctorj
El dl., 5 de gen., 2015 a les 19.18 Jason Porter notifications@github.com
va escriure:

This would be great!

On Thu, Dec 25, 2014 at 3:24 AM, Dan Allen notifications@github.com
wrote:

We should consider using Travis CI to publish a release. We could even
design it so that Travis creates the tag itself triggered by keywords in
the commit statement. The most we can automate, the more time we have to
enough the release :)

See the following post for some tips:

http://mnmlst-dvlpr.blogspot.de/2014/12/my-lightweight-release-process.html

—
Reply to this email directly or view it on GitHub
#141.

Jason Porter
http://en.gravatar.com/lightguardjp

—
Reply to this email directly or view it on GitHub
#141 (comment)
.

[abelsromero]

I just found this while looking for something else.
Leaving it here to make sure I don't forget:
https://groups.google.com/forum/#!topic/travis-ci/4e_oA0wSeUE

[mojavelinux]

👍

[mojavelinux]

@abelsromero How are you currently performing releases? Are you creating the git tag then running mvn deploy manually? Or are you using the release plugin? We should document this in the README.

[abelsromero]

First couple releases were 100% tag manual, but now I use the release plugin for the whole process. Still no automation from TravisCI.

[mojavelinux]

Thanks for clarifying. Would you mind recording in this thread the steps that you take to release? I find that writing down what we currently do is a great catalyst to get to the next stage. It also helps your future self to remember too.

[abelsromero]

Sure!

On Fri, Jul 1, 2016 at 9:46 AM, Dan Allen notifications@github.com wrote:

Thanks for clarifying. Would you mind recording in this thread the steps
that you take to release? I find that writing down what we currently do is
a great catalyst to get to the next stage. It also helps your future self
to remember too.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#141 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFg2obLcQAibufTmjrG01yy0z0VNCzOCks5qRMXzgaJpZM4DMHN1
.

[abelsromero]

I put my notes in order and wrote this wiki page:
https://github.com/abelsromero/asciidoctor-maven-plugin/wiki/Maven-release-steps

We can review it and move it to the main Asciidoctor wiki or add it as a file in the pugin's repository.

Btw, I don't forget that on the objectives for this year is automate releases.

[mojavelinux]

Thank you, thank you, thank you! That is exactly the information I was looking for. It not only helps get everyone on the same page about the current release process, it also serves as a great recipe / checklist for what we need to get the CI server to do for us. Great job!

[abelsromero]

I just reviewed it (I like to revisit manuals some hours later) and added a couple of changes. Since we already have the coveralls.io configuration in the main asciidoctor/asciidoctor wiki, I think it makes sense to add this there too.
Do you agree?

[mojavelinux]

I like to revisit manuals some hours later

Me too! I find that stepping a way is the best way to see improvements.

Yes, you can move it to the main wiki. However, I think ultimately it belongs in the repository itself (or at least the key steps), probably in the CONTRIBUTING.adoc file. The wiki should really only be used as the whiteboard, not as the canonical reference. We want the repository itself to be the single source of truth. In other words, draft on wiki, final version in repository.

[abelsromero]

OK. Allow me this then, I'd like to keep it as it is untill next release, I want to use the next release to check a few steps and see if without much changes something can be improved.
Once is done, I will add a proper CONTRIBUTING with it.

[mojavelinux]

Sounds like a good plan!

[abelsromero]

We should explore options with GH-Actions, but the current process with maven central still requires a manual step at the end sadly.

[uniqueck]

I can share my experience to create releases with CI. I use for that GitHub Actions in combination with a manual approach to create an tag.
The manual created tag pushed to github, triggers a special build with an step to extract the tag name and set this tag a an version via 'mvn versions:set -DnewVersion=(tagName without v) versions:commit. Than the release is packaged and pushed to that tag with a github action for gh release. We have to create an extract for CHANGELOG.adoc for the last version entry to push that as release notes in gh release section.
My asciidoctor extensions can acts as an starting point: https://github.com/uniqueck/asciidoctorj-liquibase-extension/blob/master/.github/workflows/release.yaml

[abelsromero]

Making this a milestone for v3.0.0 release (the last 🤞 ) as part of the efforts to make maintenance easier for a more frequent release cycle. Using GH should not be an issue, one of the main pain points was how to sing artifacts and that has been explored in #736.