Go.CD Notes

Go, or gocd is a nice tool. It will strong point you to doing “the right thing”, given that you agree with what “the right thing” is (lets save that for another day). The reason is that it’s simply cumbersome to do stupid things in gocd, like having loads and loads of shell script configuration defined in your Continuous Integration/Delivery/Deployment tool. The “right thing” is to put all of that under version control, with the source it is intented to manage.

While Jenkins is, by far, the most commonly used CX tool, and comes with loads of plugins, it has a long range of issues (again, let’s save that for another day). Gocd is much smaller in that sense, and still has a few pain points. I’ll try to list them and also what I do to not get hit as hard by them.

Tab galore - clicking frenzy

This is one comment you get from anyone having used Jenkins moving to Gocd. In Jenkins, you have all the buttons in every screen. Some of the most common ones where are:

after adding a task or job, manually triggering a new run of the pipeline that you just edited

ERR: go to the Home screen and find your job (among the other x), click the play button

ERR: or if your stage/pipeline is manually triggered, go to Home, find the Pipeline, click the title, click the correct icon (purple or the »

» thingie)

Tactic: for manually triggered pipelines, you can get away with two clicks from the Console View tab you’ve kept around
Tactic: for automatically triggered pipelines, there’s really nothing good to do here. Have a “clean” Home view.

after triggering a job, look at the console output
- ERR: click the progress bar, except if you’re in the pipeline run view, where you have to hit the circled i icon (i)
after looking at the console output: A) reschedule another run, or B) go edit the pipeline
- ERR A: see below
- ERR B: there’s cog on the Run history pages, only on the Home screen or Admin » Pipelines
- Tactic: keep multiple tabs open from the admin
adding a new pipeline in the same group as you’ve been adding the last 15 or so
- ERR: there’s no easy way to do this but go to Admin » Pipelines and scroll
- Tactic: always open “Add new pipeline in this pipeline group” in a new tab and “save” the current tab for easy re-use
Where the X can you configure persistent views, or get permalink to Pipeline Groups, or anything sensible?
- ERR: you can “customize” your Home view to only show certain pipeline groups or pipelines, but newly added pipelines will show up, and there’s no URL you can use that includes any kind of filtering
- Tactic: You could use access rights to limit what users see, but in my world view that’s disempowerment of users, which we don’t want

Why is a step called Pipeline?

I have no clue. There’s no logic explanation to why this has not been updated. Try to get over it.

I do think that most people consider “a pipeline” to be all work including the end step, such as release of a product, and all upstream bits and pieces. “How far has my fix come down the Chat pipeline, has it passed the smoke tests yet?” Gocd, unfortunately (IMO), calls the biggest building block in a pipeline, “Pipeline”. Bamboo, which has a very similar concept of Tasks, Jobs, Stages, and Pipelines, but they call the Pipeline “Plan”. It’s not very good, but it’s better.

You can almost tell that Bamboo-ism suggests not to care for the bigger picture, as there’s no easy way to do just that - see a full picture of interconnected Plans. In Gocd, getting that top level overview is both a key/core feature, and a unique feature not present in any othe r tool out there. (No, the broken, almost working “but it hides the underlying complexity of fingerprint madness” plugins in Jenkins does NOT count. It puts band aids and plaster on a broken leg. You don’t want to run your business on that.)

Seriously, why isn’t it running yet?

Scheduling of work, and picking it up, in Gocd is still based on a pull mechanism. The build slaves, called agents, calls in to the server every now and then to check for work, and eventually gets it. This easily adds up to minutes for any series of Pipeline steps.

This is the flow of things right now:

a Material (such as the URL to a git repo) is scheduled for polling, either via time - typically every 60 seconds - (globally setting for all Material) or using HTTP API (which doesn’t support webhooks from GitLab, GitHub, Bitbucket, …)
gocd server now polls the Material (clone or update) to see if there actually was any changes to pickup
if changes where found, the Pipelines setup to use this Material are now scheduled for being picked up by a suitable agent
an agent polls for work every n seconds

Issues where this is reported:

What? You’re telling me I can’t rename a stage or pipeline?

“No, that’s right unfortunately. You’ll have to either fix it manually through the XML config (yeah), or pause all related pipelines, break all dependencies, rename, re-add dependencies and unpause all pipelines.”

Hmm, where can I put my comments?

As others have pointed out, Jenkins offers an ability to comment on builds. This is useful when you have many people that look at your pipelines and some decide to start investigation, or simply “don’t touch this build as we’re doing something with it”. There’s a beta feature for this on the Pipeline level, only visible from the Run history view.

What the he** - how are these pipeline groups and pipelines sorted?

Errh, dunno. Someone rolled a dice? :-)