5 ms·
It looks like the challenge is tracking cloud resources created as part of a CI infrastructure and not Jenkins itself. Jenkins can be nothing but a scheduling a
by iwwr 5y ago
It looks like the challenge is tracking cloud resources created as part of a CI infrastructure and not Jenkins itself. Jenkins can be nothing but a scheduling and execution engine, not quite a self-service platform for business workflows.
It may help more to define more precisely a few scenarios where you experience problems, so people can be more specific with suggestions.
Lacking more specific information, you might consider putting automatic self destruct / deprovisioning for created cloud resources, e.g. 7 days, so you don't worry as much about what is created. What also helps is idempotency in these scripts, to just tell developers to retry things if there are transient errors.
- shtubi 5y agoThanks for the comprehensive answer. I did apply a destruct mechanism, but many times devs need the resource for longer or shorted periods, which makes it hard for them & me to manage it :/
- iwwr 5y agoHow about to ask developers to provide a job parameter DURATION, and some suitable default like 0.5 days?
- boguyona 5y ago"Jenkins can be nothing but a scheduling and execution engine, not quite a self-service platform for business workflows." -you are totally right. Do you have suggestions for a tool for a "self-service platform for business workflows"?
- iwwr 5y agoNo idea as of yet. There are some better ways to represent workflows so they are more easily composable and/or visible, there could be a startup in there :) Some things tried: totally custom solution (most flexible), GitLab (unlike Jenkins, you can define a pipeline as a graph), BPMN (pretty heavy Java solution, you still need to build a frontend, there are a lot of tooling but kind of big overhead and low flexibility), Airflow (good visualisation, good for short duration workflows, there is some infrastructure overhead).