-
Notifications
You must be signed in to change notification settings - Fork 40
RFC: Remove resources based on github issue/PR/branch #45
Comments
I think the use case makes sense, but I would try to keep GitHub and its API out of kube-janitor. I actually have a similar scenario (but without involving GitHub) to check conditions externally, so we could think of some hook mechanism, e.g. by passing a Python function to do whatever external check. |
@hjacobs sure, a plugin system would be fine for my case. Do you have an idea of how that would be managed/configured? |
@jasongwartz I imagine something similar like the auth hook here to validate users or similar: https://kube-web-view.readthedocs.io/en/latest/oauth2.html |
That makes sense to me. I guess users could save the function body in a configmap and volume mount it in. I can take a look at your implementation in kube-web-view and attempt a similar technique - are you happy to see a PR or would you rather implement yourself? |
@jasongwartz happy to see a PR, please note that I won't be responsive in the next weeks 🏖️ |
We have the same use case. We are using skaffold to provision ephemeral environment as namespace based on PR. We are currently using kube-janitor to delete dangling resources not removed by skaffold or if developer forgets to delete the environment. |
Resource hooks are now implemented, so this feature could be implemented without changing |
Great! Thanks for the update, @hjacobs 🎉 |
I'll keep this issue open, because an example hook for GitHub PRs would be nice to have 😄 |
This is a proposal for an additional feature, so I wanted to get feedback on the idea before starting on an implementation.
Our use of kube-janitor at Ecosia is as follows: we create a QA/review environment as a k8s namespace for every PR, and after a TTL has been reached (eg. 7 days), we delete the namespace. We would rather automatically delete the namespace based on the PR status change (eg. closed or merged), and we’ve tried a number of techniques for this (CI on the merge commit, github actions, etc) and none are particularly consistent or clean, yet.
It occurred to me the other day that for our use-case, kube-janitor could have a different kind of annotation, eg
janitor/github-pr
orjanitor/github-branch
, that would use the github API to check if the PR is open, or the branch exists, and remove the annotated resource when that condition are no longer met. In summary, if the annotationjanitor/github-pr: “ecosia/example-repo/101”
existed, kube-janitor would use the github api to check if the PR number 101 on the repo ‘ecosia/example-repo’ was still in ‘open’ status.Please let me know if this is a feature you’d be willing to include and if so, I can try, sometime in the near future, to take a crack at an implementation.
Cheers! 🙂
The text was updated successfully, but these errors were encountered: