ci: Introduce workflows (according to what we do in kubeflow-rocks) in order to:
Build and publish ROCK on dispatch.
Build, scan and run sanity and integration tests on PR for each ROCK that was modified by it.
tests: Add sanity tox environment that replicates the unit one without the
copy-rock-to-docker and rockcraft pack part. This way, those steps
are decoupled and tests can be triggered from integrate.yaml workflow.
files: Add .gitignore
Closes #58
Question to reviewer
Should we run build, scan and run tests for mlserver? As mentioned in this issue of mine https://github.com/canonical/seldonio-rocks/issues/61, this ROCK is not used by Seldon and thus we won't scan it for CVEs report too. At the same time, it doesn't make sense to run integration tests for it. ATM, there's no integration tox environment and calling integrate.yaml for it will fail. Thus, we could probably remove it from the on_pull_request.yaml workflow.
sanitytox environment that replicates theunitone without thecopy-rock-to-dockerandrockcraft packpart. This way, those steps are decoupled and tests can be triggered from integrate.yaml workflow..gitignoreCloses #58
Question to reviewer
Should we run build, scan and run tests for
mlserver? As mentioned in this issue of mine https://github.com/canonical/seldonio-rocks/issues/61, this ROCK is not used by Seldon and thus we won't scan it for CVEs report too. At the same time, it doesn't make sense to run integration tests for it. ATM, there's nointegrationtox environment and callingintegrate.yamlfor it will fail. Thus, we could probably remove it from theon_pull_request.yamlworkflow.