search

cs3org / reva

WebDAV/gRPC/HTTP high performance server to link high level clients to storage backends
https://reva.link
Apache License 2.0
170 stars 113 forks source link

CI: build and publish separate container images for testing (long-lived) feature PRs #976

Open SamuAlfageme opened 4 years ago

SamuAlfageme commented 4 years ago

For now, reva and revad container images are just being built for master (latest) and tags. Having a separate pipeline and registry (dockerhub/quay) dedicated to building the images from feature PRs could enable more people to test and validate them, as we do for https://reva-releases.web.cern.ch/reva-releases/daily/

The CI job should have the option to be skipped-on-demand based on the commit message / PR labels. I think enabled-by-default makes sense since most of the reva PRs are new features/fixes.

See GitLab's "review apps" pattern as an example; it follows this same principle (without the deployment step, in our case - even though it'd also be feasible to deploy a preview as we do for the docs on netlify).

What do you think? cc/ @labkode @phil-davis

phil-davis commented 4 years ago

webDAV and OCS end-to-end API tests are in place and cover a lot of the API-visible functionality. As a handy side-effect they will end up exercising much of the functionality of the "backend" microservices that are doing the work behind-the-scenes. If someone is fixing an existing bug or refactoring code, then the test coverage is quite likely to exercise their code and prevent regressions. If they are fixing externally-visible behavior then they will be forced to adjust some tests, and will know that the change is "good" because the test passes. So green CI gives a reasonably level of confidence in the change. After merge it will end up in the next daily build.

For real "features" this might be useful - e.g. when implementing some API functionality/endpoint that has not yet been implemented at all. In that case the developer will be enabling whatever end-to-end tests currently exist for the functionality, and probably creating more test scenarios. They, and others that want to see/try the progress of the feature might find it handy to have the container image available.

I'm not sure whether opt-in or opt-out default is best.