Normalizing and standardizing environments

[brianbruggeman]

Given the issues I had experienced with just the testing aspect, I am proposing here a Makefile shim which standardizes specific, common development operations including but not limited to:

• builds
• qa
• style
• testing

The primary goal here is to limit the amount of ramp-up time anyone new would need to have in order to start contributing and simultaneously reduce the differences across development environments so that debugging differences becomes simple.

Additionally, I think the shim could also be used in CI though I'm not sure I have actually access to the Travis output (it looked like notifications were sent to a team specifically at Aerospike). Despite being sanctioned under the Aerospike umbrella, since this particular project community driven, it makes me wonder if Github's Actions are a better option. The only downside I see here is that a Makefile approach is probably limited to a Posix environment. As a consequence, it probably wouldn't work for Appveyor/Windows.

[jonas32]

Great Idea.
I dont really see a problem as long as the compatibility to running the client itself on windows stays like it is.
Right now, Appveyor is not running DB tests. Its just checking if something breaks in the compile step.
We could let the Linux tests run that Makefile and leave appveyor as it is. (I dont think anyone is going to use this client on a windows machine in production anyways).
You can at least access the direct output of the builds by pressing them in your pull request. I always used Draft PRs for that.
That way, the CI will also run on your branch and execute the tests.
For example here: https://travis-ci.org/github/aerospike/aerospike-client-rust/builds/756731191

[jhecking]

The Travis build logs should definitely be open and are linked from the PRs, as Jonas pointed out.

I think using the Makefile in the CI builds would be a good idea - at least for the builds in Travis. However, the Travis builds currently start a 2-node Aerospike cluster, which your Makefile currently does not support. There also needs to be a mechanism to wait for the cluster to have formed, before the tests are run. Both of these things are accomplished by the .travis/start_cluster.sh script. If you can integrate that logic into the Makefile, then I don't see a problem switching over.

Also, there's already some internal discussion about moving from Travis to GitHub Actions. But no final decision yet.