I‘m not sure what’s bad about executing arbitrary groovy scripts because you are running arbitrary code anyways (unless Jenkins is not running any code at all – e.g. compile static assets, do something else). If some developer wanted access to the secret files – config files which might have sensitive information such as the database password for the staging environment (I don’t know what they are called in Jenkins) they could just modify the code to dump them to stdout.
I am asking this because I don’t see a problem with running turning compete scripts if the application is most likely to run arbitary code anyways, which has access to syscalls any many other dangerous stuff anyways. You need to trust your employees anyways and if you can’t trust them with not dumping the staging environment in purpose, you should not have hired them. It is possible to include harmless looking code which can be malicious and still be considered a bug if found during code review’s.
The point is that you get mu hich better reuse by not allowing arbitrary groovy and building up interface contracts. This is exactly like any other coding. Using groovy is akin to allowing arbitrary SQL from your web devs intead of apis (from an interface pov not security).
Instead just invoke something outside of Jenkins groovy framework like maven, make, etc. Makes you much more portable and upgradable.
Jenkins should just be your execution/workflow environment not a dev framework.
Also never mutate the worker boxes, everything should be completely isloated from itself and each other.
Jenkins is like any other software architecture.
Finally doing too much in Jenkins makes it impossible to test Jenkins locally, which means you can neither debug builds locally without pushing new code to build, nor can you test alterations to Jenkins itself locally which makes it much much more fragile.
How do I know? I'm a sr dev coming in and fixing a mid sized engineering org (400+ devs) jenkins 4 years of accretions. These are major issues we've identified in just a week of looking.
Build systems should be simple, scalaboe, agile, and composable, not monolithic. Keep the monolithic to the individual builds not cross company.
Got it, my groovy files have always been setup the environment (I.e. write config files for the test database, API keys, etc everything that should not be in git), and then just execute make to make so that I don’t have a completely different setup each environment. Thank you very much!
> Finally doing too much in Jenkins makes it impossible to test Jenkins locally, which means you can neither debug builds locally without pushing new code to build, nor can you test alterations to Jenkins itself locally which makes it much much more fragile.
If you would have used Jenkins pipelines, you would know that you can debug it directly from the UI. I can make my builds hard to run locally on configuration-based systems as well, this is not really an argument against Pipelines.
> How do I know? I'm a sr dev coming in and fixing a mid sized engineering org (400+ devs) jenkins 4 years of accretions.
You haven't used Jenkins Pipelines though, if you would have used it, you would know about the debugging part I mentioned above.
> Build systems should be simple, scalaboe, agile, and composable, not monolithic. Keep the monolithic to the individual builds not cross company.
These have nothing to do with the actual topic, these are just generalisations.
> The point is that you get mu hich better reuse by not allowing arbitrary groovy and building up interface contracts.
You can reuse the groovy code you write, which means you actually get more reuse.
> This is exactly like any other coding. Using groovy is akin to allowing arbitrary SQL from your web devs intead of apis (from an interface pov not security).
That is a bad analogy, a correct one would be something like: writing NodeJS build scripts in JavaScript instead of using Grunt or Gulp, or Groovy vs. Maven/Ant.
> Jenkins should just be your execution/workflow environment not a dev framework.
What is a "dev framework" in your mind?
> Also never mutate the worker boxes, everything should be completely isloated from itself and each other.
What does that have to do with using a programming language instead of a config DSL?
> Jenkins is like any other software architecture.
Fail to see how that vague statement supports your argument.
>If you would have used Jenkins pipelines
Nice, way to start off with an ad hominem attack. Yes I'm lying to you about having used pipelines. That's what I do, I go on hacker news and lie about what I do, especially jenkins, to throw people off the scent. Seriously... if people dont know that pipelines are easily debuggable, that's a problem with the documentation, not with the person. It's also not a reason to attack people.
I have used jenkins pipelines. However I didnt use it from scratch so no, I couldn't do what you said due to all of the other issues. My point is that it does let you hang yourself, I prefer the config based systems as it's harder to hang yourself.
Your NodeJs anology is more apt but who cares you got the point. This is a discussion not a literature critique.
A dev framework to me is the type of stuff you've built up around a typical compile of a given "stack". For instance, doing ruby on rails, you're likely to have a bunch of build tooling you've built up to make that easier. I would prefer to distribute that stuff more generically and unrelated to jenkins vs some other build system, as opposed to building it all into jenkins.
As for mutating workers... you seem to be under the mistaken notion that I'm discussing the one thing you are discussing. But in general, if you have a turing complete language with complete system access like you do in the groovy, you can do anything and anything isn't always a great idea. I like the config based systems as it doesn't allow you to do anything, it allows you to do things we've deemed as good for building software. Jenkins boxes end up being shared resources in a large company so it's very difficult to audit what everyone is doing and side effects they are causing.
>Fail to see how that vague statement supports your argument.
Ok
>You can reuse the groovy code you write, which means you actually get more reuse.
You can but most people don't know how to or dont. It's a break from your typical dev loop and it's yet another framework to learn. I don't think it's effective unless you dive in and most people don't dive in. So to me it's a bad model. This is opinion.
I am asking this because I don’t see a problem with running turning compete scripts if the application is most likely to run arbitary code anyways, which has access to syscalls any many other dangerous stuff anyways. You need to trust your employees anyways and if you can’t trust them with not dumping the staging environment in purpose, you should not have hired them. It is possible to include harmless looking code which can be malicious and still be considered a bug if found during code review’s.