Lizardfs: Setup CI Builds With GitHub Releases ( And Other Notes on Releases )

[zicklag]

This is somewhat related to #440 so @onlyjob you might be interested.

---

I wanted to know how the LizardFS developers would feel about getting automated builds setup for LizardFS on Drone. Drone is an Open Source CI server that I have experience with that also has a public cloud hosted for free for Open Source projects on GitHub. There would be no cost associated with establishing the builds.

I would want to get CI setup to push the built packages to GitHub releases whenever a release is made. I think it would be great for community testing if we also setup builds that would run on every push to master. These builds could upload the built artifacts to a specific latest-master release where anybody could try out the current latest commit of LizardFS. Obviously this latest-master release would have no guarantees of its stability.

If this is something that the dev team is fine with then I can create a PR for the build script. I could also tweak the workflow however you would like.

For the release strategy, I'm assuming a workflow of:

• Make commits/PRs to master
  
  
  
  • Every time master is updated the latest-master release on GitHub releases is updated with freshly-built packages
  
  
• Get master to a point where it is ready for release
• Create a release tag on master with the new version number
• CI builds the release tag and pushes the built artifacts to the GitHub release

That is just the model I had in mind for the CI script but I'm not sure exactly how things are done currently so this could be adapted to whatever you need.

[zicklag]

Anybody have any input on this?

@antonboretskyi I'm going to be working on the Juju deployment for LizardFS and, while this isn't required, GitHub releases would help automate the container builds that I have to make against the LizardFS release artifacts and would aid in allowing us to provide deployments for newer versions of LizardFS.

[aNeutrino]

Hi @zicklag & @onlyjob you both are correct that that LizardFS needs to get rid of _release mess_.
Our current team has:

• desire
• need
• motivation

To make CI green again!
Our engineers are using many of good practices in their pet/home projects: like for example @AmokHuginnsson has nice numbers in test coverage, also coverage of @jadolg is nice and his projects have nice badges, both are using CI build in GitHub... so we know our toys, we just need to bring them to LizardFS, and we decided to do it as a first task after (too) long silence in the project.

We also acquired new hardware:

• with over 200 cores 400 threads
• good 10GbE network & 100GbE
• and interesting sets of HDDs/SSDs/NVMes configurations

...which is aiding us in this task of zero tolerance for bugs and state of the art CI & deployment.
including GitHub releases.

That's said ... I am not closing this issue until you - experienced users - say so, please watch and guide us during next weeks about this important issue :)

Please also note that we still use Gerrit Peer code review with newest code changes...

[zicklag]

@aNeutrino That is great to hear! Thanks for the update!