Automated releases

[crabhi]

Hi, we use your plugin. To be able to upgrade ES versions, I've automated the release process. If you're interested in it, here you are.

There are a few smaller changes bundled:

• Tests were not being run because Log4j 3.0 alpha1 was used. I couldn't make it work with version range so I just hardcoded Log4j version - the same as other dependencies.
• It seems enough to get Lucene that comes with ES and we don't need to specify its version here.
• I separated this plugin version number from the ES version number. Basically copied from monitora-media/es-utils where we need to make changes to the plugin independently from ES upgrades.

[vhyza]

Hi @crabhi,

thank you for the PR. I'm sorry I didn't get back to you sooner. I'm quite swamped with other projects and as I do not use the plugin for years now, my motivation is not the strongest.

Anyway, I'd like to get back one day, but it will probably take some more time. I'm sorry about that.

[crabhi]

No worries! It's not blocking me in any way. 😃

[crabhi]

And thanks for your open source project. Had it been closed, it would be much harder to keep it up to date. 🙇🏿

[pySilver]

@vhyza your plugin is awesome. maybe someone would like to take over and maintain it?

[vhyza]

Hi @pySilver,

thank you for your kind words.

I hope I'll find some time during the summer to finally process the pending issues and pull requests.

The problem is that the plugin release is still a somewhat manual process. I thought about the CI/CD pipeline for a long time, but as the manual publish is approx 10 minutes per elasticsearch version I always rather do the release.

That was fine when I had time to do it before new elasticsearch versions started to accumulate.

As I released more than 150 versions of the plugin I'd like to release all the missing versions. Ideally not manually :-).

So I was thinking that I first try to get changes from this PR made by @crabhi, especially to try the GitHub workflow and dependency changes together with the work made by @vit-zikmund in #39.

After the dependencies are updated and resolved (like Log4j etc) I'd like to "stress-test" the workflow to release the missing versions and process the rest of the PRs:

• Updated for elasicsearch 8.13.2 and Lucene 9.10.0 #42
• Prepare plugin for Elasticsearch 7.17.20 #41
• Upgrading to Elastic 8.9.2 #37

Also if the Workflow somehow allows starting elasticsearch with some particular version (for example using git tag as all releases are tagged) I think it would be nice to add a test which installs the generated plugin and runs simple sh script testing that the plugin works by sending curl request to for example _analyze elasticsearch endpoint.

To be honest I never used GitHub Workflows (I am more familiar with Gitlab-CI or CircleCI) so I do not know yet if the following is possible. I was thinking something like:

• when a new tag is pushed workflow starts
• run Java tests
• build a plugin if Java tests passed
• install the plugin using the correct elasticsearch version
• run elasticsearch with the plugin installed
• run test script
• if everything is ok, release the result as a new GitHub release

As the pending PRs sometimes overlap I probably won't be processing the PRs as a whole but most likely cherry-picking the changes. I'll try my best to keep the credit.

I really appreciate all the work done in the PRs ❤️. I hope during my summer vacation I'll have some time and energy to start the work. If not and there is someone who would like to help with it I can add him/her as a repository collaborator.