Open SamuAlfageme opened 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.
For now,
reva
andrevad
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