search

aquarist-labs / aquarium

Project Aquarium is a SUSE-sponsored open source project aiming at becoming an easy to use, rock solid storage appliance based on Ceph.
https://aquarist-labs.io/
Other
71 stars 23 forks source link

test: Set up CI/CD for labs #20

Closed asettle closed 3 years ago

asettle commented 3 years ago

CI/CD needs to be setup for labs.

Requirements are not known at this time - this needs to be investigated further.

jhesketh commented 3 years ago

We should aim to do this in a "githuby" way. It'd be great if we can use a public instance of Travis or something that is not our slow Jenkins/ECP.

It'd also be good to have the CI defined inside the project instead of in a separate repository. How that exactly looks depends on the target platform, but I'd have it as a priority feature. (and hopefully something better than jenkins pipelines :-s)

kshtsk commented 3 years ago

@jhesketh does travis provide as much resources as we need?

asettle commented 3 years ago

For CI, just an FYI: https://github.com/marketplace/category/free

Also worth considering: https://github.com/marketplace/circleci/plan/MDIyOk1hcmtldHBsYWNlTGlzdGluZ1BsYW45MA==#pricing-and-setup

asettle commented 3 years ago

@kshtsk it might be worth investigating using Zuul for our CI/CD - https://zuul-ci.org/docs/zuul/reference/drivers/github.html#github-driver

Both @jhesketh and I have experience with it.

kshtsk commented 3 years ago

@jhesketh our jenkins is fast, the slow point is ECP which is located in the datacenter with very low bandwidth outside. Another thing is delivering build artifacts to ECP, it is implementation specific. For example, using container images for cluster deployment on the other end of earth is super inefficient. But it is not the worst case, when I run those test on my laptop from my pace with 10megabit DSL router, it becomes dramatic... like 4+ hours. You experienced slowness with system deployment which is always expensive.

The unit test and component tests we are running do not use ECP at all.

kshtsk commented 3 years ago

Maybe we split this issue into separate ci tickets:

Or we should keep discussion what and how many layers of integration test we should have?

jhesketh commented 3 years ago

Maybe we split this issue into separate ci tickets:

* setup unit test github actions

* setup static analysis (lint?)

* setup deployment or smoke test.

Or we should keep discussion what and how many layers of integration test we should have?

Happy to split it into separate issues, but item 1+2 are otherwise already done so we can just leave this as discussion on setup deployment and smoke tests.

kshtsk commented 3 years ago

Submitted a script for testing deployment what we have at the moment as a separate repo https://github.com/aquarist-labs/wasser

Corresponding config is on its way to merge to main branch of aquarium https://github.com/aquarist-labs/aquarium/pull/265

For now it is setup as a jenkins job and defined based on the example https://github.com/aquarist-labs/wasser/blob/main/examples/jjb/aquarium.yaml

We enable it as automatic run for each PR.

The workflow is to check steps from https://github.com/aquarist-labs/aquarium/blob/main/doc/from-zero-to-hacking.md with minor changes to make it working on openSUSE Leap 15.2 host.

On Tumbleweed it does not work for me at the moment, since system is slightly different.

Since we're doing CI, which is a development process and evolves as far as the product developed, and system is constantly improves as well as new requirements appears, and initial setup is done we are ready to close this ticket as soon as #265 is merged. All further improvements suggests should be handles as separate 'issues'.

kshtsk commented 3 years ago

Closing this, for new features there should be specific issue opened.