3 ms·
I agree with this. The quality of your Jenkins experience will be pretty much inversely proportional to how much groovy script is in your Jenkinsfiles. Every n
by mikepurvis 5y ago
I agree with this. The quality of your Jenkins experience will be pretty much inversely proportional to how much groovy script is in your Jenkinsfiles.
Every new permutation of parameters is a new chance for something to go wrong, and there's basically no sane way to unit test or validate any of your "helper" functions, so they're all write-once-change-never.
Which is not necessarily a problem inherent in Jenkins— Jenkins just gives you more than enough rope to hang yourself. GitLab CI can get silly too, but culturally it inherits from the much simpler Travis model, where you're basically expected to just be wrapping some other build tool (eg, tox from the Python world) rather than rolling the whole thing yourself.
- outworlder 5y agoGroovy is arguably the wrong language choice, even if it worked fine in other aspects. The string handling situation alone is crazy, which is compounded if you are using it with bash (which has its own crazy ideas about string escaping). That's a not too uncommon scenario. You end up with this: https://gist.github.com/Faheetah/e11bd0315c34ed32e681616e41279ef4 https://gist.github.com/Faheetah/e11bd0315c34ed32e681616e412...
- mikepurvis 5y agoTo be fair, basically everything that interops/embeds bash like this ends up in a similar place— you see the same double-escape ridiculousness in CMakelists files and Nix package definitions.