I'd like to use an other project to promote my builds.
I am using this plugin https://wiki.jenkins-ci.org/display/JENKINS/Promoted+Builds+Plugin
But I have the following error message when I am linking a project
This is working but not really properly.
Promotion logs:
Started by user admin
Building in workspace /var/lib/jenkins/workspace/generator-api
Promoting generator-api #86
build hudson.plugins.parameterizedtrigger.BuildTrigger#36339454 SUCCESS
Warning: this build has no associated authentication, so build permissions may be lacking, and downstream projects which cannot even be seen by an anonymous user will be silently skipped
Finished: SUCCESS
I should have the deploy build there as well.
I can't find how to give permission to my project to build deploy when promoting.
From what I can see the downstream project should have Run as User who Triggered Build options selected in Configure Build Authorization section.
In my case that options is missing. To enable that see following Jenkins plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Authorize+Project+plugin
EDIT
I solved the problem in different way. I had this code in execute shell of promote section:
git tag -d DEVENV
git tag DEVENV ${PROMOTED_GIT_COMMIT}
git push origin --tags —force
Problem was that the tag didn't exist and the script was failing on the first line trying to delete it.
It is very likely that the auth warning message is vague and hides different problems.
I was having similar issue when trying to add new trigger for building another project, and this seems to resolve it:
With the Authorize Project plugin, you should go to "Access Control for Builds" section, in the Global Security athttps://{your-jenkins-domain}/configureSecurity/:
Adding a new strategy "Run as SYSTEM", allowed the Jenkins Cron scheduler to trigger build on another project.
Note however, that the red warning "You have no permission to build" did not disappeared, although it did not prevent the triggered build to be launched by the scheduler.
Related
My understanding of Jenkins is that, if you have a repo (say a Git repo) that is tied to a Jenkins build, a check-in will trigger a complete repo re-build. But if you have a number of applications as part of your repo, is there a way to limit which applications will rebuild in response to a check-in? If you make a change to one application, is there a way to set up your Jenkins build process to that that check-in triggers a rebuild of that application alone?
I'm sorry but your understanding is wrong... Jenkins and Git talk to each other using hooks and if these hooks are connected to your build, only then will they build the application/branch in your repo... So unless you have specified that everything must be built, then all the application will be built, otherwise the one you checked in ...will trigger only that build
If you want, you can create a new job and add the GIT SCM hook(during configuration) and do a check in, it will build only your project and any other project that is using the same hook- key point to note here :)
So if all your applications are building then you have a configuration issue
Hope this helps :)
When I do some code changes and push the code to Gerrit. Jenkins build gets triggered and we usually get verified voting +1 or -1 depending on the result on to the Gerrit UI for that change.
Currently, we observed that for any of the compilation errors it is not reporting on to the Gerrit. And this happens only for compilation errors, not for failing tests, failing git checkouts or other reasons that make a build fail.
Below I've mentioned the version details. Any suggestions will be highly appreciated.
Gerrit Version: 2.14.2
Jenkins Version: 1.642.3
Gerrit-Trigger plugin: 2.18.3
Project: Java project
Build Tool: Maven
Regards
Sharieff.
That's intended for an "Unstable build" (i.e. compile/build errors but not a test error) in the default Gerrit-trigger configuration.
Take a look at your "Gerrit Reporting Values" for the project/default configuration.
If you want to use the "verify" label for unstable (i.e. compile errors) and failed (test errors) builds, configure the verify values like seen below.
(iirc the default configuration uses code-review = -1 for unstable, for this the used gerrit account needs the permission to submit a code-review label)
Jenkins should notify bitbucket if a job that is linked to a branch has passed or falied, and it does:
But for some reason, in the branch view, it doesn't notify about the result of the last build, and says it failed even if the last build has passed:
How do I make it refer to the result of the last build only?
Today it was released a new version of the plugin for jenkins bitbucket-build-status-notifier which allows exactly what you need to avoid the problem you describe. It's new config option "Only show latest build status", just ensure this checkbox is checked and enjoy it.
Hi I'm the maintainer of the bitbucket-build-status-notifier for Jenkins. Actually the plugin creates a new build status for every jenkins build execution for a given commit. That means that if you exec a build for a given commit id and it failed and later exec a new build for the same commir id and success, both status success and failed will remain in bitbucket, that's find and not an issue. Anyways I understand your problem or desires and you are not the only one since there's already a issue
for solving it.
At the moment I've not much time for developing this new features but I'll do it as soon as possible.
Is there any way in jenkins where as soon as we detect the failed build, job revert back the perforce code to the last successful build changelist and fire a build again.
Flow -
1. so as soon as we have failed build - Notifcation will be sent out to dev team with possible checkins which causing the build failure
Revert back the recent code to the last working code and submit it
Initiate a build.
It is possible, but I don't see any reasons or use case to do it as it is not a correct workflow and can be confusing.
But if you decided to do it, the next steps are required:
Example how to do it using Perforce source control.
Steps inside job settings:
Before build triggers you need to save latest changelist number $P4_CHANGELIST - 1
Perforce plugin for Jenkins: Perforce plugin for Jenkins
Build
Get last error code
Get last error code from the: batch
If code != 0 then checkout and build changelsit $P4_CHANGELIST - 1
Jenkins is not a production server. It runs tasks and do not have options that I know for that purpose.
What is your source code ? webapps ? others ?
What steps are you performing ?
Are you performing some automatic tests ?
My assumption is that you got some tests that may invalidate the build.
These tests should be runned :
* on a mock server to prevent deploying on your server
* or somewhere else
Like that, if build failed, nothing is deployed.
If build success, you can deploy your project normally.
If this not reply to your answer, please provide requested information to undestrand a bit more your job process.
If your using an artifact repository like Nexus or Artifactory to manage your project artifacts then you could always redeploy the previous working version of your application when a failure is detected.
Your not cancelling any checked in code that potentially broke the build but you are preserving your test environment. You can configure Jenkins to notify the user who checked in the latest erroneous change set and they can work on resolving the issue.
Jenkins also provides a rich API which allows you to delete a job, start a job, get information about previously run jobs. You could leverage some of these services along with your artifact repo to achieve the experience you described.
There are two machines with Jenkins: one for building, second for testing. If some job is successful on 1st machine, it triggers testing job on 2nd machine via http request. For example:
http://<2nd_jenkins_ip>:8080/job/<job_name>/buildWithParameters?BUILD_NUMBER=167
The problem: It seems that there is something, which launches some of the testing jobs automatically, but it shouldn't. I have deactivated nightly builds, but it happened again. And I can't find out the reason.
Question: Is there any possibility to display the IP/url of the machine, which started the build (e.g. into console output)? If not, can I find this information elsewhere (e.g. jenkins/linux logs)?
EDIT1:
Console shows:
Started by user anonymous
Building on master in workspace <my_workspace>
Cleaning local Directory ./test_data
Checking out ...
Following svn checkout and other build steps.
In the Jenkins_HOME directory on the server, look under jobs/<jobname>/builds/<select the last build you want by date>
In there, open log file (no extension) with any text editor. It will usually provide a more detailed cause at the top of the file.
There are many ways you can prevent unwanted builds. One way is to configure Authentication Token under Job's configuration -> Build Triggers -> Trigger builds remotely. Once a token a set, other (rogue/old) scripts could not trigger the job without providing this token.
This however does not prevent manual triggering through the UI or other projects triggering through Jenkins' methods (not URL).
I've also had some inconsistent issues regarding jobs that were configured on a schedule/timer to the effect that changes wouldn't take effect until Jenkins restart.