Post History

[Dirk's answer](https://software.codidact.com/posts/286480/286481#answer-286481) provides a sound solution to the literal problem you describe. Nevertheless, I would encourage you to take a step back and consider whether you _really_ want to be editing Makefiles in a Jenkins job.

The idea behind Jenkins, as set out in their [best practices](https://www.jenkins.io/doc/book/pipeline/pipeline-best-practices/) guide, is that the Jenkins pipeline is "glue" code which _invokes_ the build process of your software. It is not supposed to _become_ the build process.

If your Jenkins pipeline performs complex tasks like editing Makefiles, you are going to have a divergence between how the software is built on Jenkins, and how it is built on developer machines. This can lead to surprising behaviour later. For example, build errors may occur on Jenkins that no developer can reproduce locally; after a few hours of frustration, you (or a future colleague) finally realise that Jenkins is using a completely different Makefile to what the developers are using.

If you need to patch Makefiles, it would be better to patch them in the source code so that developers are building with the same process as Jenkins. If the problem is that the Makefiles need to be patched differently on different systems, it might be better to solve this by parameterising the Makefile (with environment variables or command-line arguments), or switching to a cross-platform build system like CMake.

Perhaps none of these suggestions are appropriate for your situation — you might have a very specific need to patch Makefiles in Jenkins which cannot be addressed any other way. But be aware that the more complex your Groovy pipeline, the more likely it is that you are going to see Jenkins-only build problems that are awkward to debug because no developer is building software the same way that Jenkins does.