-
Notifications
You must be signed in to change notification settings - Fork 4
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
Support ephemeral instances #6
Comments
Hi @Nothing4You, Picus current supports AWS and Hetzner. The AWS agent provider is using one instance which is started when new jobs are pending and stopped when all jobs have been done. So the same instance is used all over. In order to support ephemeral instances the concept for the AWS agent provider in Picus would need to be changed. The Hetzner cloud agent provider in Picus starts a new instance when a job is pending so here we have a clean start situation. The instance is shutdown when there no more jobs for a certain time. For Hetzner cloud you pay for every hour that the server is running so when you shut it down after a few minutes you still have to pay for a whole hour AFAIK. So having ephemeral instances for a less trusted envionment might be possible in general but has some implications. |
I see, I'm primarily a Hetzner Cloud user, so I didn't realize that it's handled differently for AWS. As a reference, GitLab CI supports setting
|
Hetzner bill for each machine whether it's running or not, as the resources are reserved for you. Ideally, the scaler should check agent runtime and only delete an idle agent near the top of the current billing hour to minimize costs. |
That seems like a separate issue for optimizing hetzner cloud costs. This issue is explicitly for discarding VMs after every single build job, at the cost of paying for the full hour regardless, to allow untrusted builds to be performed in clean environments, without risking them being able to impact any other builds. |
Hi,
I'm not sure how reasonable this is to implement, but it would be great if this could be used with instances that can only run a single pipeline before being destroyed.
Implementation wise, this may be doable by deploying a new instance, waiting until it has accepted its first job, then disabling the agent in woodpecker, which will prevent it from picking up new jobs.
This would allow running CI jobs automatically even in less trusted environments, as every pipeline will have its own clean environment.
The text was updated successfully, but these errors were encountered: