search

ghale / gradle-jenkins-plugin

Gradle plugin to programmatically configure Jenkins jobs.
123 stars 42 forks source link

workflows and good practices #79

Open feyrob opened 8 years ago

feyrob commented 8 years ago

Without having used GJP before, I expected a workflow similar to this:

If I understand correctly, this is not possible with GJP. Once the gradle build file has been updated to represent the target state, GJP is not 'aware' of removed jobs anymore.

Is there a good known practice for removing old Jenkins jobs when using GJP?

I can imagine some weird workarounds (e.g. execute task:deleteJenkinsItems with previous version before executing task:updateJenkinsItems with new version), but I think it most likely that I simply have not identified a good workflow yet which other people are already exercising.

What are good GJP workflows and practices? Are there accessible GJP installations that could be looked at to learn about working practices?

philbert commented 8 years ago

I'm learning the GJP too but your issue made me curious. So far, the GJP works the way I expect it to, within the boundaries of how I know jenkins works.

My answer to your question would unfortunately be "it depends on what you change"

The GJP doesn't do anything special regarding keeping track of the jobs it has created. So for example if you change something in the build.gradle file that alters the project name, then there neither gradle, nor jenkins understands that you may wish to rename an existing job. It will instead create a new job with the new name and leave the old job behind.

You will hit another problem if you try to change the job type for example. Jenkins will return an error saying that the job already exists. There is no way to change the job type once the job is created. You need to delete it and create a new one if you wish to use the same project name.

Workflow-wise, unfortunately, I don't have any good recommendations what you can do to fix this in a nice way. I think you already hit upon the obvious one that you checkout the older version of the build.gradle file that created the jobs and run deleteJenkinsItems.

Alternatively, I think that I am more in favour of implementing some type of job versioning that you can add as metadata in the description field, and have a separate cleanup job that sweeps away anything that is not the latest version (or some other smarter formula). Since that cleanup job is just script with an arbitrary level of complexity, you could make it as aggressive or permissive as you like.