My use case is to replace a "Run docker container" step with an equivalent step that runs on Kubernetes instead. The current step relies on the image being set at build time, so it sounds like the only way to do that would be to create a cloud profile at build time. Is it possible to create the cloud profile via a groovy script in a build step?

That will not work, as cloud profiles are expected to be exist before any builds using it started and managed independent of the builds.

Robin, what if we had separate job to set up cloud profiles via API? We have a lot of them and expect them to change periodically. Basically the model would be something like

• generate new build container
• generate cloud profile for new container
• update source to reference the new cloud profile when building

Or can you suggest another approach to better automate this?

drdt

Robin, what if we had separate job to set up cloud profiles via API? We have a lot of them and expect them to change periodically. Basically the model would be something like

generate new build container
generate cloud profile for new container
update source to reference the new cloud profile when building
Or can you suggest another approach to better automate this?

This approach should work if the build does not need to use its created profile. For details on how to create/edit cloud profile via API, please check:

Or you can interact with groovy using same approach as outlined in CloudProfileResource.java

Robin, you know I have always been a troublemaker. So after trying what you suggested above, we took it one step further (I have been working with Tyler). We have a job like this:

• master (on server): sequential step
• • create-cloud-profile (on server): groovy script that creates a cloud profile, sets attribute "CLOUD_PROFILE=$profileName"
• • use-cloud profile (on agent with attribute "CLOUD_PROFILE=$profileName"): "hello world" script.

This works for us! The second step creates a new build agent from the newly-created cloud profile and uses it. Is this because the cloud profile exists before starting the step that needs it? Your statement before indicated that the profile needs to exist before the build starts, but we seem to have found a back door...

However, I don't want to try this in production without understanding the implications. I can send you the code for your examination.

No problem at all. This approach works as you only use created cloud profile in subsequent steps. I thought master step of the build uses the cloud profile previously.