This is a good idea. For avatica-go, I've implemented something similar using a bash script and docker-compose [1] [2]. For avatica, I've also implemented a bash script and docker-compose for making releases [3] [4]. Hopefully, this is something we can do for avatica as well, then we can remove the bash script and use docker-compose to wrap around Gradle (for those who want to run the release build process in docker).

Currently I've the following steps automated (see avatica's HOWTO for more details [5]):
1. Build release.
2. Upload release to dev svn respoitory and generate vote email.
3. Tag final release and push and then move rc release to the release svn repository.

[1] https://github.com/apache/calcite-avatica-go/blob/master/docker.sh
[2] https://github.com/apache/calcite-avatica-go/blob/master/docker-compose.yml
[3] https://github.com/apache/calcite-avatica/blob/master/docker.sh
[4] https://github.com/apache/calcite-avatica/blob/master/docker-compose.yml
[5] https://calcite.apache.org/avatica/docs/howto.html#making-a-release-for-calcite-committers

On 30/05/2019 8:09 pm, Vladimir Sitnikov wrote:
Update: I think Gradle-based build for JMeter is 99.42% complete, and I'm
quite happy with that (the link is still
https://github.com/apache/jmeter/pull/448 )
I have commands like "./gradlew prepareVote" that builds artifacts, stages
them to dist.apache.org / repository.apache.org, builds documentation
preview, publishes it along with RAT report to a Git repository (e.g.
GitHub pages preview), and prepares "[VOTE]" email.
Note: I have stub implementations for Nexus, SVN (
https://github.com/vlsi/asflike-release-environment ), so everybody can try
that out with zero risks of updating apache.org servers.

I have "./gradlew runGui" that builds artifacts and launches the app
automatically (== which would be very handy for our ./sqlline since we can
delegate classpath build and cache to Gradle)

If you are feeling lucky/curious, please check out apache/jmeter/pull/448
and try loading the project in IDE / executing some commands (there's a
list in PR description)

The only "sad" point I found is Kotlin-based build scripts take a bit to
compile (e.g. it might take 10-20 seconds to compile "10 build scripts"
after modification of the core build file), however I think it is not a
problem since we don't modify build files often. Subsequent executions are
super-fast.

Vladimir

Reply via email to