Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Notifications
Mark all as read
Q&A

How to open a file and edit its content in groovy script

+5
−0

I have a Makefile in my Jenkins job's workspace, that I want to edit out certain parts from and then save it, before running next part of the script that uses this Makefile.

The part that I want to cut out is this:

PUMP_MARKER:=,cpp
ifneq (,$(findstring $(PUMP_MARKER), $(DISTCC_HOSTS)))
PUMP:=pump
else
PUMP:=
endif

I am looking for some shell command that I could put in my Groovy script, that will open up this file and remove this above mentioned part, save it and then move on.

Here is how my Groovy script looks like:

stage('Build'){
  dir ("$WORKSPACE/$SVN_TAG") {
    Here- I want to insert some shell command to edit that file out
  }
}

Note: I know I could just vi that file and manually do this but I want to do this for multiple jobs and I'm genuinely looking for something that I can just paste in my every Groovy script and automatically do this.

Why does this post require moderator attention?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

2 answers

+4
−0

One simple possibility to eliminate a set of lines with precisely known content is to use the patch tool. The below code shows an example shell script.

The script calls patch on the file to be modified (in this case foo.txt). The patch tool then also gets on the standard input the diff it shall apply. This is in the code below achieved using the "here document" mechanism from the shell, see the << followed by the quoted identifier END. Quoting END is necessary to ensure the subsequent diff text is not subject to expansions.

patch foo.txt <<'END'
1,6d0
< PUMP_MARKER:=,cpp
< ifneq (,$(findstring $(PUMP_MARKER), $(DISTCC_HOSTS)))
< PUMP:=pump
< else
< PUMP:=
< endif
END
Why does this post require moderator attention?
You might want to add some details to your flag.

1 comment thread

@Dirk Herrmann Thank you soooooooooooo much (1 comment)
+4
−0

Dirk's answer 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 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.

Why does this post require moderator attention?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »