Skip to content
This repository has been archived by the owner on Oct 3, 2020. It is now read-only.

RFC: Remove resources based on github issue/PR/branch #45

Open
jasongwartz opened this issue Nov 5, 2019 · 9 comments
Open

RFC: Remove resources based on github issue/PR/branch #45

jasongwartz opened this issue Nov 5, 2019 · 9 comments

Comments

@jasongwartz
Copy link

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 or janitor/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 annotation janitor/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! 🙂

@jasongwartz jasongwartz changed the title RFC: Remove resources based on github issue/PR RFC: Remove resources based on github issue/PR/branch Nov 5, 2019
@hjacobs
Copy link
Owner

hjacobs commented Nov 6, 2019

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.

@jasongwartz
Copy link
Author

@hjacobs sure, a plugin system would be fine for my case. Do you have an idea of how that would be managed/configured?

@hjacobs
Copy link
Owner

hjacobs commented Nov 7, 2019

@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

@jasongwartz
Copy link
Author

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?

@hjacobs
Copy link
Owner

hjacobs commented Nov 9, 2019

@jasongwartz happy to see a PR, please note that I won't be responsive in the next weeks 🏖️

@asoni90
Copy link

asoni90 commented Jan 16, 2020

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.
Also, it would be great if kube-janitor can track the helm charts and delete them as well.

@hjacobs
Copy link
Owner

hjacobs commented May 14, 2020

Resource hooks are now implemented, so this feature could be implemented without changing kube-janitor itself: #64

@jasongwartz
Copy link
Author

Great! Thanks for the update, @hjacobs 🎉

@hjacobs
Copy link
Owner

hjacobs commented May 14, 2020

I'll keep this issue open, because an example hook for GitHub PRs would be nice to have 😄

@hjacobs hjacobs reopened this May 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants