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

Add ability to cancel runs #12

Open
lusu007 opened this issue Jul 6, 2024 · 2 comments
Open

Add ability to cancel runs #12

lusu007 opened this issue Jul 6, 2024 · 2 comments

Comments

@lusu007
Copy link
Member

lusu007 commented Jul 6, 2024

No description provided.

@meyfa meyfa changed the title Add possibility to cancel runs Add ability to cancel runs Jul 14, 2024
@meyfa
Copy link
Member

meyfa commented Jul 14, 2024

So far I have not found a way to implement this. Even if we exec into the pod, there is no way to terminate Renovate without the pod being marked as "Failed", and subsequently getting restarted.

ps aux inside the pod shows the following process hierarchy:

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
ubuntu         1  0.0  0.0   2368  1024 ?        Ss   21:08   0:00 dumb-init -- renovate
ubuntu         7  0.0  0.0   5736  3328 ?        Ss   21:08   0:00 /bin/bash /usr/local/bin/renovate
ubuntu         8  0.0  0.0   5736  3328 ?        S    21:08   0:00 /bin/bash /usr/local/bin/node /usr/local/renovate/dist/renovate.js
ubuntu         9 49.1  9.5 32835976 774928 ?     Sl   21:08   2:40 /opt/containerbase/tools/node/18.20.3/bin/node --use-openssl-ca /usr/local/renovate/dist/renovate.js

No matter which of these processes I terminate (kill -s SIGTERM <pid> or kill -s SIGKILL <pid>), the pod is marked as failed - which makes sense, I guess.

However, this leads me to believe we can only "cancel" a run by deleting the Job itself - not the Pod. In that case, any logs would be gone, along with any trace of this action being performed. This seems bad from a monitoring/auditability perspective.

@meyfa
Copy link
Member

meyfa commented Jul 14, 2024

I suppose in theory we could override the command of the Renovate container so that it runs Renovate as usual, but traps SIGTERM & exits gracefully. This might work for runs triggered manually via the Foreman UI, at least. Arguably it's more likely someone wants to cancel a manual ran than a scheduled run. However, this seems like a fragile implementation at best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants