ca-scribner
commented
9 months ago Some thoughts on each case:
on_pull_request
Definitely we need:
- build
- scan
- test (whatever test means... that could be its own debate :D Especially when talking about integration testing)
Should we also:
- publish to dockerhub
- Arguments for: helpful during development. Could be useful during debugging. Makes it easier for people to review PRs (reviewer can just use the image rather than spend 15 min building one themself)
- Arguments against: noise in the dockerhub repo? This wouldn't be as bad if we only publish the rocks that changed
- save the rock file itself somewhere so it can be pulled by a developer? Is this overkill?
- (anything else?) ?
on_push (to a branch that produces releases, like a specific version)
- build
- scan
- test
- push to dockerhub
- (anything else?)
When this CI publishes, do we need to create a release or something like that? Or, if we version everything with commits, is it clear enough? There is the problem @orfeas-k you mentioned about if we need to republish something without actually modifying the repo (and thus without changing the commit hash) - those might still need some breadcrumbs to know what is where. But this is a small case
orfeas-k
syncronize-issues-to-jira[bot]
What needs to get done
At the moment, we do not have standardized and explicitly decided what should happen during
on_pushandon_pull_request.on_pull_request
The second part is tackled by PR https://github.com/canonical/charmed-kubeflow-workflows/pull/27 which introduces
get_modified_rocks_and_build_scan_test_rock.yamlthat is designed to suffice for checks duringon_pull_request. That's the thought also behind this implementation in seldonio-rocks. However, AFAIK, we haven't decided explicitly that build, scan and testing should happen during on_pull_request. This can also be observed by the fact that we have differenton_pull_requestworkflows in kubeflow-rocks and pipelines-rocks repos.on_push
At the moment, there is nothing in this repo that can just be triggered as is for
on_pushevents. There is the build_and_publish_rock.yaml file but cannot be called without passing arguments for each rockcraft inside a repo (as opposed to what can be done usingget_modified_rocks_and_build_scan_test_rock.yaml. We should thus decide we expect from CI on those events.The above should happen with the use of reusable workflows (if possible) in order to have a centralized way of controlling ROCKs CI and avoid copy-pasting the same files over many repos.
Why it needs to get done
We need to do this in order to have centralized CI for ROCKs that will be reusable, robust and easily transferable. We will also avoid hardcoding and copy pasting stuff.