How to find a particular text in entire codebase - Groovy Jenkins - jenkins

Within a Jenkins-Groovy pipelines I want to do the following:
Clone a particular GitLab based Code repo.
Then within this repo I want to find out all the files where there is a particular string. Example: "find_me"
Once found I want to change all these files from find_me to found_me.
Then commit these changes to the GitLab repo.
Step 4 above maybe I can find out myself, but I am struggling on how to do the 2nd and 3rd steps mentioned above.
Can anyone please suggest what can be the best way to do this?

Pipeline: SCM Step
findFiles: Find files in the workspace
readFile: Read file from workspace, writeFile: Write file to workspace, prependToFile: Create a file (if not already exist) in the workspace, and prepend given content to that file.
You can't commit to a GitLab repo directly from within Jenkins. You add/commit/merge locally, then you push. See, for instance: Is it possible to Git merge / push using Jenkins pipeline.

Related

How to use a GitLab link for applying jenkins.yml file for the concept of Jenkins Configuration as Code

I have a local instance of Jenkins. I have previously tried storing the jenkins.yml in my system and giving its path on http://localhost:8080/configuration-as-code. This worked but I want to use a Gitlab repository to store the jenkins.yml file.
I have already tried giving the gitlab link of my jenkins.yml in the path or URL textbox. Some weird things happened, like
1. jenkins broke or huge error console
2. It reapplies the previous configuration(from system path)
jenkins:
systemMessage: "Hello, world"
Your problem as described: you want the job configuration to be saved in GIT and, when a build is triggered, the job should get the current stand of its configuration from there and then, run the build.
Maybe there is a kind of plug-in that does it for you, but I am not aware of any. Maybe anyone?
My suggestion is to define a pipeline job and use a declarative pipeline. It is a file, normally named Jenkinsfile that can be stored in GIT. In the Job, you define the GIT address and when you trigger a build, the file is got from GIT and executed.
There are several flaws in this: pipelines learning curve is not small, you are confronted with groovy (not XML!) and your current XML file is barelly useful.
Maybe someone shows up and tells us about new (for me) plugin that solves your problem using the configuration XML file. In the other hand, pipelines are such a beautyful feature that I encourage you to give it a try

How to collect report from copy artifact plugin

I use Jenkins to build complicated project from different sources. Last build copy artifact from previous builds and create product. I want to get report what exactly were copied(build name, build number, changelog of source build, etc)
Final build have no upstreams and started manualy or by commit into own git repo.
I think groovy postbuild step can help me. But i do not understand how to get access to CopyArtifactPlugin Property.
I find this workaround by parsing build log.
You can see gist here

Creating artifacts in jenkins

I have been tasked with looking into using Jenkins as a build server. So far I have managed to pull a project from git, restore the Nuget packages, build the project and run the unit tests. However I am struggling to find out how to generate the artifact.
The way the business would like to have the build server generate a zip file to a directory on the build server or a remote server for the systems team then to pick up and deploy to the relevant location. E.g. given a windows service project the built bin directory would be zipped up and put in the relevant artifact directory.
I thought that in order to do this I add an archive the artifacts post-build action. However I am getting the below error:
‘Watchdog.WinService.Monitor/bin/Release/*.zip’ doesn’t match anything:
‘Watchdog.WinService.Monitor’ exists but not
‘Watchdog.WinService.Monitor/bin/Release/*.zip’
If I look in the workspace for this project I can browse to the bin directory and see all the files so I unsure what I have done wrong.
Can someone please let me know if what I am trying to accomplish is possible, and also if our approach to using Jenkins is correct?
The problem is that you try to create the artifact using the archive artifatcs step.
But the step is to collect artifacts and show them on the job page.
That means you need to create the artifact first e.g. using a shell or batch script.
You can combine this with the Flexible Publish Plugin.
When you select this as post build step you can create a conditional action that runs the artifact archive task and as condition executes the script that creates the zip file.
So if that fails the task won't be executed. Also it may causes your job to 'fail' but that may not be the case in your job.

Publishing to Artifactory using Jenkins

I am trying to use the Generic Jenkins-Artifactory plugin to deploy the contents of the Jenkins build workspace into Artifactory. This seems to be somewhat fine using the following wildcards
Web\*.msi=>Testing\Web
Web\DeploymentSettings\*.xml=>Testing\Web\DeploymentSettings
Database\Scripts\**=>Testing\Database
However, when it comes to moving the contents of 'Database\Scripts' from the Jenkins workspace, empty folders under 'Database\Scripts' do not get copied into Artifactory. Non-empty folders however are copied successfully. It is important that I maintain the directory integrity/structure so it's a must that I copy these across.
I have considered placing empty text files in the empty directories to have them copy over successfully but I don't want to "pollute" the package.
Please help :-)
Thanks!
Looks like there is no workaround -other than dummy files in the directories.
I see some bugs in Jenkins releated to handling empty directories.
JENKINS-7260 Clone workspace doesn't copy empty directories when cloning entire workspace
JENKINS-20654Empty folders are not copied to the slave
Could you check if answer posted in Hudson: Copy artifact from master to slave fails helps?

Jenkins creating wrong folder for the new jobs that were copied from other existing jobs

Sorry, for the confusing title. I am totally new to Jenkins and have been handed over Jenkins to maintain which was set-up by someone else.
This is Jenkins Master slave config. I have 1 Master and 3 Slaves.
When I create a new job by "copying an existing" job, the new job works fine and no issues.
QUESTION: I see that in Jenkins workspace, this new job is creating a folder with the name of the original job that it was copied from. Why it is not creating a folder with the name of the new job instead?
Now, this is certainly not a show stopper for me, but it seems that Jenkins is creating a folder in workspace for each job that is run. And hence this particular folder is causing some confusion (although notional it is).
Hence, could you help me find out why the new job is creating a workspace folder with the name of original job it was copied from.
BTW, above issue was seen on the Jenkins slave.
It can be solved by configuring the correct building workspace in jenkins job.
General > Advanced > custom workspace > "give your correct workspace"
I had the same problem:
copied some jenkins project and wondered about hard coded workspace paths
Console output of the copied project. Job failed due to missing D: drive.
12:30:44 java.io.IOException: Failed to mkdirs: D:\TEAMS\WORKSPACE\RELEASE_1_1
The problem i had: the 'Advanced project options' were not expanded and the configure GUI had an enormous width, that i didn´t see the button to expand and show the 'advanced' settings.
In fact (thanks to sti): the original project had some hard coded workspace path.
One possibility is that you accidentally triggered the wrong job. You could change the job to print the directory where it executes by adding something like:
echo "XXX $JOB_NAME running in directory $WORKSPACE"
into the build step script. Then look for XXX in the build console log.
Second possibility is that you found an old workspace of the original job. Jenkins leaves workspaces lying around just in case it needs them again so it does not have to make them from scratch.
Third possibility is the original job is configured to use a hard-coded path as workspace. (Custom workspace). If you clone such a job, it would be a good idea to change the hard-coded path. An even better idea would be to let Jenkins manage the workspace and it's naming.
And finally, if all the other possibilities have been checked, you may have found a bug. You could look for it in https://issues.jenkins-ci.org/ and create a bug report if it is a new one.

Resources