You can (and should!) do exactly the same with “traditional” GitHub Actions style YAML.
Avoid putting commands in the YAML - put those in separate scripts and call them from the YAML. The YAML should only be used for things that can’t be done from scripts (e.g. job matrices, uploading artifacts, reporting status etc.)
Seems reasonable but good fucking luck enforcing that.
IMO they should instead simply charge cost price for hosting. It can’t be much surely?
I totally agree about story points being bollocks. Their supposed justification is that you can measure velocity by seeing how many story points you do per month, but that only works if there’s no feedback from velocity to story point estimation which is obviously not the case.
So in practice they just become a stupid proxy for time. “1 story point is an hour right?”
The Fibonacci thing makes some sense to me though - it is a way of suggesting that bigger estimates are less accurate.
Of course it would be much better if you could actually put an accuracy directly into Jira or whatever (e.g. 10-30 hours), but that would apparently be way too complicated. You could also get that data fairly nicely from planning poker (which I also think is pretty good, but you throw away all the information about uncertainty that you just spent ages discovering!)
I really hope they don’t copy how Git does submodules and LFS. They’re both pretty terrible.
It allows the CI engine to determine which jobs to start, what their steps are etc.
To be fair I have worked on one project that had very complex CI and we almost decided to generate the CI graph procedurally with a Python script (Gitlab supports this, somewhat awkwardly). But in the end we decided it wouldn’t be worth the overhead of writing, maintaining and learning a whole new CI system on top of Gitlab’s CI.