Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI for triggering a delete of the ns #930

Open
xtineskim opened this issue Jul 28, 2022 · 2 comments
Open

CI for triggering a delete of the ns #930

xtineskim opened this issue Jul 28, 2022 · 2 comments
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: cleanup An internal cleanup or hygiene concern.

Comments

@xtineskim
Copy link
Contributor

Describe the bug

I had to manually delete some ns of past PRs that were closed, for example #765, #727, even though they were merged/or manually closed. While this is not a super concerning, I would like to keep our resources running at a minimum to avoid incurring more charges.

To Reproduce

Not sure if it's reproducible, I didn't want to close any PRs. We can try opening fake PR and triggering the pr on event workflow?

Logs

n/a

Screenshots

n/a

Environment

n/a

Additional context

Whoever investigates this can reach out to me!

Exposure

n/a

@xtineskim xtineskim added type: cleanup An internal cleanup or hygiene concern. priority: p3 Desirable enhancement or fix. May not be included in next release. labels Jul 28, 2022
@bourgeoisor
Copy link
Member

@NimJay is this something you've seen recently by any chance?

@NimJay
Copy link
Collaborator

NimJay commented Oct 25, 2023

  • Yes, this issue still exists.
  • For instance, today, I see the workloads for pull-request 2201 still running inside the online-boutique-prs GKE cluster (of our Online Boutique CI project).
Screenshot 2023-10-25 at 7 43 02 AM
  • The last time I did a manual clean up of this issue was around Aug 24.
  • Today, there is only one PR that needs cleaning up (the PR mentioned above).
  • The Aug 24 manual clean-up was for 10 pull-requests:
    • pr1636
    • pr1637
    • pr1640
    • pr1761
    • pr1767
    • pr1768
    • pr1939
    • pr1940
    • pr1943
    • pr1944
  • Since we only got this issue once between Aug 24 and today (Oct 25), I assume we get this issue about once a month, so the p3 priority makes sense.
  • Let's investigate when our team has more bandwidth. For now, a manual clean-up every few month is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority: p3 Desirable enhancement or fix. May not be included in next release. type: cleanup An internal cleanup or hygiene concern.
Projects
None yet
Development

No branches or pull requests

3 participants