Concurrency for GitLab runners has to be set explicitly

I found out there's a concurrent setting for self hosted GitLab runners that has a default value of 1, preventing you from having several runners run at the same time:

Limits how many jobs can run concurrently, across all registered runners. Each [[runners]] section can define its own limit, but this value sets a maximum for all of those values combined. For example, a value of 10 means no more than 10 jobs can run concurrently. 0 is forbidden. If you use this value, the runner process exits with a critical error.

Despite having my setup running for several years, with 3 available runners, I never realised that jobs within the same stage in my pipelines were not running in parallel. They do now, after raising the value of concurrent.

While I was at it, I also changed my pipeline configuration. The last stage is called vanity and runs things like black and pylint to check whether the code follows conventions. I made these jobs have allow_failure set to true, in order to make GitLab not consider pipeline runs failed if any of these jobs don't turn out green.

Some advice on making software

Jim Grey shares some advice after 35 years of making software:

Chase adventure and interestingness, not salary and title. This might be controversial with some, for whom salary and title are critical. So be it. We’re ridiculously well paid in this industry, even at the entry level. I’ve had a varied career, from technical writing to QA to engineering. I’ve said yes to, or chased after, things that sounded like would be challenging and interesting, and therefore fun. The money and positions have come to me in time. I might have gotten them a lot faster had I chased after them instead. What I got was a fascinating career and a great deal of personal and professional growth. I regret a couple choices, and a couple other choices totally didn’t work out for me. But there’s so much opportunity in this industry (even though the downturn we’re living through has tightened that up for now) that you can recover from that.

The above and more advice on Jim's blog.

Positive revolutions

@requiem shares some thoughts:

So what I’m taking away from my more recent (1960’s) anarchist studies is that history tells us we really need to focus on how what we’re proposing will be good instead of focusing on what’s wrong with the way things are going otherwise.

This, more so than warnings or preaching against the status quo has more often led to spontaneous revolutions by autonomous individuals as opposed to the “coalition led” revolution myth.

I won’t belabor this (I can recommend some books) but what’s clear is that if we want a revolution that lasts and doesn’t just setup another tyranny our efforts today could be well-spent first dreaming and then building the future we want and doing this in public instead of simply pointing at what’s wrong and trying to motivate change through fear. That’s what “the machine” uses, and it’s better at maintaining the status quo than inspiring people to make changes.

I’ll be working hard to take my own advice.