Client 3872 add ci scripts

[gagan405]

1. Ports CI scripts from java client package
2. Added Sonatype publish / delete workflow
3. Modified snapshot checking logic : is-snapshot not available from build info
4. Modified scripts to work with non-matrix manner - we just have 1 artifact
5. Modified scripts to handle all hierarchy of the artifacts: parent and child artifacts
6. Modified the versioning logic - if no tag - snapshot

Testing:

Tested with commenting out all portions that could alter anything anywhere.
Latest can be seen here: https://github.com/aerospike/aerospike-client-java-reactive/actions/runs/20125452454/job/57754079729

The workflow is failing at later stages as it doesn't exist in main branch.

Actual run

First: a build and release should run on pushing to stage -> that should publish to internal JFrog
Second: when the build is done, manually this promote workflow can be triggered after adding a release tag to the stage branch

[mirzakaracic]

I think this is great stab at it and should get you to release packages. The aerospike-client-java-reactive project is following similar dev workflow for shipping as most other clients other than python, that is PR -> stage -> main.

[mirzakaracic]

suggestion: take commit hash/branch name after workflow name

Would be possible to leave everything after the filename, aka @<version/branch name> since we have gh-workflows-ref? I have not tested this my self but seems repetitive to have the same information twice. It makes it confusing and error prone to have the same information in two different places.

[gagan405]

Looks like we cannot omit it, since it is from a different repository. Based on the docs:

https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows#calling-a-reusable-workflow

You reference reusable workflow files using one of the following syntaxes:

{owner}/{repo}/.github/workflows/{filename}@{ref} for reusable workflows in public and private repositories.
./.github/workflows/{filename} for reusable workflows in the same repository.

In the first option, {ref} can be a SHA, a release tag, or a branch name. If a release tag and a branch have the same name, the release tag takes precedence over the branch name. Using the commit SHA is the safest option for stability and security. For more information, see Secure use reference.

[mirzakaracic]

Looks good other than the commit hashes.

[mirzakaracic]

There is also a failing test.
https://github.com/aerospike/aerospike-client-java-reactive/actions/runs/20146087249/job/57826769359?pr=64

Could it be wrong project?

[gagan405]

There is also a failing test. https://github.com/aerospike/aerospike-client-java-reactive/actions/runs/20146087249/job/57826769359?pr=64

Could it be wrong project?

This is expected. The correct URL expects a build number, like this:

API_PATH="/api/build/aerospike-client-java-reactive/42?project=database"

I was trying with enforcing the workflow to run on PR, with some hardcoded build number.

It can be ignored now.