Jenkins: Suppress builds after commit by a system user possible? - jenkins

have a localiziation build in Jenkins (sources are in SVN) that has a commit by the build user as last build step - due to shortcomings of the used localization tool (Passolo).
Is there a way to suppress the triggering of a new build when the commit was done by this special build user or to kill those jobs immediately?
TIA, Franz-Josef

The solution ist to use the "revprop" attribute in your build script, like so:
svn commit -m "Commit via Jenkins" --with-revprop NoAutoBuild
Inside Jenkins configuration, you can exclude revisions using this property from starting a new build, you find the option in the SVN section of the Jenkins configuration page (screenshot, alas, in German):
sreenshot showing the "exlude revprop" section of the SVN plug-in inside Jenkins configuration
Hope this helps you (and me, if I forget until next time :-)

Related

How to build Jenkins after each push in any branch?

Is there any way to make Jenkins builds after each commit in any branch ?
Because i found in my project's configuration that Jenkins run build only after detecting commits in specific branch or in the default ( eq to master in git ).
PS: i'm using mercurial and Jenkins file.
Should i change project type ( new item type in Jenkins ) or are there any modifications in configs.
There are two things that you should check for this (I haven't work with Mercurial)
Does Mercurial has the option to create webhooks?
There is a jenkins plugin for Mercurial? (I think there is)
You must configure on the mercurial site the webhook pointing to Jenkins and give the point to the job you want to run, and on which events does it will fire. On the Jenkins side you must configure on the job who it will behave.
For example, with GitLab, the plugin has an option configured on the "Build Trigger" section where you configure the events and the branches that fires the job. In GitLab, in the repository you create the webhook, that is only a URL pointing to the Jenkins job.
I got this solution and it worked for me.
with Mercurial, we can use the "tip" keyword.The tip revision is the most recent changeset in the repository. It is the most recently changed head.

How to run Jenkins pipeline automatically when "git push" happens for specific folder in bitbucket

I have started using Jenkins recently and there is only scenario where I am stuck. I need to run "Jenkins pipeline" automatically when git push happens for specific folder in master branch. Only if something is added to specific folder, than pipeline should run.
I have already tried SCM with Sparse checkout path, and mentioned my folder, but that's not working.
I am using GUI free style project, I dont know groovy.
I had the same issue and I resolved it by configuring the Git poll.
I used poll SCM to trigger a build and I used the additional behavior of Jenkins Git plugin named "Polling ignores commits in certain paths" > "Included Regions" : my_specific_folder/.*
By the way, using Sparse checkout path allows jenkins to checkout only the folder you mentioned.

How do I re-run a build?

All our Jenkins jobs are configured to build changes on all branches in a repository. There are times where we want to re-run a specific build that ran against a specific commit.
a build fails because some external resource was unavailable and we want to re-run that commit once the resource is up again;
a job depends on an internal package and we need to be able to re-build specific branches to pick up the latest version of that package.
Jenkins' "Build Now" command, however, builds on the branch of the last build. It doesn't let the user choose what branch to build on. In order to rebuild a branch, users have to commit and push a change to that branch.
Is there a plugin that will allow the user to re-run a specific build or choose the branch to build on? If you've used TeamCity, I want the "Re-run with same revisions" feature.
We've tried both the Naginator and Rebuilder plugins. Naginator only lets you rebuild failed builds, but also automatically re-builds failed builds at least once (not desireable). Rebuilder always rebuilds the last commit. It behaves just like the "Build Now" button.
The Rebuild plugin is probably the closest plugin to what you want however as you have found it only will get HEAD and not a specific git revision.
This is an open feature request.
The comment on this question notes the same thing.
All that being so I would still suggest that you should perhaps reconsider the idea of depending on the git revision to drive the outcome of your build. You should want to build the HEAD.

How to suppress Jenkins groovy Logs

I am trying to execute Jenkins checkout command to checkout source files from subversion repository. When I execute command on a new workspace, it will display complete logs of checkedout files. Is there a option to disable logs and enable only when it is required?
Seems like a quiet checkout improvement is in the works, but not yet released.
https://issues.jenkins-ci.org/browse/JENKINS-14541

git clone only on new change and archive scm

I am using to Jenkins to pull code from git in every 10 minutes and then compiling, archiving it for other jobs to clone this workspace. Currently it's pulling code from git every time and then archiving every time.
I want to clone code from git only if there is any new change else it should skip and do not archive the workspace. Which plugin should I use and what configuration I should make in that?
So it sounds like you have a couple things going on here. Here is some possible suggestions that I use to meet similar needs:
1.) If you are only wanting your job to build when there is a change in your source control, in this case GIT, you can use the "Poll SCM" plugin. And then in there set a cron expression to run every 10 minutes.
"Poll SCM" plugin will check source control for any changes and build the job when it finds them. If this works properly your job will not build thus it will not archive anything unnecessarily.
2.) For archiving I would make sure to utilize the "Discard Old Builds" plugin and "Advanced" section to keep a rotation and retention policy for your jobs artifacts.
3.) You state "for other jobs to clone this workspace". Are you actually having other jobs pull in this jobs workspace? Or did you mean copy its artifacts? I ask because the workspace is temporary, in a sense, and you should pull the artifacts. There is a plugin for that as well called "Copy Artifact Plugin" that you can use and it allows for various options.
4.) An alternative to "Poll SCM" plugin, if it doesn't work or you do not prefer this, depending on your GIT setup you could also potentially setup a hook that will notify Jenkins of changes. There are various hooks depending on the GIT implementation.
Hope this helps!

Resources