job.sh

I will argue for the job.sh-approach.

What is job.sh? Consider you want to automate a couple of things during development (which is just an example, this goes for any other task too). You'd likely have at least build, test, deployment steps. Steps that can be fully automated and put in test.sh, build.sh and deploy.sh shell-scripts. If they are configured purely via the environment you can run them on localhost, just like having them run by some automation tool; Maybe a CI/CI solution that's triggered whenever you push to your repository. As mentioned before, nothing fancy here. The trick is to stay that simple, KISS the simple! Don't let any vendor lock you in by using uberfancy features.

This is really not too inspired and not conceived for the first time. Yet, time and time again i see almost the exact opposite done in the field.

But how?

Start local and make all job.sh scripts work on your machine.
Configure everything through the environment.
Do the same for any tool that's supposed to run job.sh scripts too.

Tools that do not support this are the wrong tools. Know where you're aiming (running job.shs) and choose tools and what not after that fact.