Milamber>credentials must be provided

Maven can read credentials from settings.xml, etc, etc.

Milamber>Thus, a lot of steps are manual because the step need an human
checks
Milamber>(javadoc warning, archive checks, RAT report, etc)

What is the point of manually checking javadoc warnings?
Could we just fail the build if javadoc warnings are present?

What do you mean by "archive checks"?
Of course we want to have multi-stage process like:
1) Prepare release candidate artifacts
2) Manually inspect them (e.g. people from all over the world check if
artifacts run on their machines)
3) Hit "promote" button that would make the release generally available

I think #1 could be automated via Jenkins/Travis kind of job.
Of course "jmeter/ReleaseCreation" page could be kept for emergency cases,
however it is a pity the release procedure is so hard to follow.

It does not matter much if we use Docker or not for the release though,
however I find it is better to use the same set of tools that is used
during regular CI.
Do we use Docker for regular CI checks?
I don't think so. That is why I think we do not want to maintain two
different ways of building JMeter.

Philippe>        - how could we improve ?:
Philippe>        - jenkins job ?

I guess the question boils down to: "is it acceptable to store private part
of GPG key somewhere".
For pgjdbc I use Travis as a release job:
https://travis-ci.org/pgjdbc/pgjdbc/builds/421151967  It assembles a
artifacts (builds for different Java versions) and uploads them to Maven
Central.

For JMeter, Apache Jenkins job might be good.

The most complicated steps to automate in my opinion are related with "site
update".
That is "update changelog", "update versions in readme". Good-looking
"notable changes" page can hardly be automated.

For pgjdbc we have a script
<https://github.com/pgjdbc/pgjdbc/blob/master/release_notes.sh> that
automatically creates "... released" web pages based on the CHANGELOG.md
(which is populated manually with notable changes)
Well, we even fetch contributor names from GitHub automatically
<https://github.com/pgjdbc/pgjdbc/blob/d43398a5d4c173da40e8f283f9e5fe20a971de5c/release_notes_filter.pl#L47-L60>
to populate the list of contributors in release notes

Of course it takes a while to setup, however I think it pays off.

Vladimir

Reply via email to