On 29/08/2018 11:52, Vladimir Sitnikov wrote:
Milamber>credentials must be provided Maven can read credentials from settings.xml, etc, etc.
I don't talk about maven, but the steps about gpg sign and ant rc_upload/publish.
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?
Currently a javadoc warning don't stop the release creation. I don't know if we can configure to stop if a warning occur.
What do you mean by "archive checks"?
Verify that the source and binary archives contains the good files and that's no missing (new) files.
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.
Yes the #1 (ant distribution task) can be done by any build tool (every day if we want have a project "ready to distribute")
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.
I mention Docker to help the developer to have an build environment on his machine independently to the operating system of his machine. The ASF build environment (jenkins) is already on linux platform and all building tools are present. No need to use Docker to 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.
+1 if we could find the good way to manage the credential (gpg and ASF login/pass). Perhaps ask to the Infra team or ASF member list if a way already exists (I can do this if you want)
Milamber
Vladimir
