Let me begin by stating this entire process was set up by a former employee. I understand how to use Jenkins and set up new items, but that is about the extent of my knowledge. Everything has been working fine for years, but about a month ago all builds started failing.
When looking at the configuration for each job I see this message:
Comparing the console output from successful builds to that of failed builds I also notice some differences. I do not know what they mean though.
A successful build:
Then a few days later the same job failed to build. I do think there were plugin updates or something done in between.
Can anyone help me solve this to get our development flow back up and working properly? When files are pushed from Bitbucket it automatically kicks off a Jenkins build which pulls the files into our staging server. Since Jenkins is not working correctly I have to manually FTP any new files to our staging server which takes a lot of time.
It seems that you are missing the credentials for the Github repository.
Jenkins as extensive documentation on how you can add a credential secret:
https://www.jenkins.io/doc/book/using/using-credentials/
Here is a simple tutorial for it:
https://www.thegeekstuff.com/2016/10/jenkins-git-setup/#:~:text=Setup%20Jenkins%20Credentials%20for%20Git&text=To%20add%20a%20credential%2C%20click,Use%20default.
Related
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.
I am looking for implementation of CI/CD in to my current project here is what i think will work.
Environment consists of
- Jenkins
- git
- docker
- gradle
- Linux servers
- Sonar
- Ansible.
Each tool will be used as following.
Git:- Developers will push there code to this CVS.
Jenkins:- On detecting Check-in Jenkins will trigger a build and will deploy to one of the server.
Sonar:- will be used for code coverage and will check the code before building the same through Jenkins.
ansible:- ansible will be used to quickly prepare added nodes so that code can be deployed to them.
Docker in case if we need fresh test environments every time we can use docker+ ansible combo for doing the things.
Flow of work will be
User run unit test cases on his machine and commits the code to the server.
Jenkins will pull the code from git and will run sonar on the same and will generate reports.
jenkins will create build and will deploy the same on dev server.
A jenkins job will run and will perform the integration testing on the dev server
Any other automated tests can be run.
Finally builds pushed to next server using Jenkins.
I will use shell commands inside Jenkins to push compiled code from one server to another.
In my this scenario can some one answer me following.
Where will sonar get fit and how to use the same?
I see there are CD tools, cant i push compiled code to the servers using shell scripts written inside the Jenkins jobs to automatically deploy the things? What extra benefits a CD tool provides
Is is wise to create fresh test environment or we can keep using the old one again and again?
Will this complete CI/CD?
can someone share there implementation
You say you plan to use Git. I'll outline a scenario using Git on GitHub
Developers push code changes here as pull requests
The SonarQube GitHub Plugin kicks off an initial analysis of only the code changed in the PR looking for the introduction of new issues (note that coverage and duplications are not included in this check)
Once the PR is merged, Jenkins (in one job or several, depending on your needs)
builds
fires integration tests & any other automated tests
runs SonarQube Scan. Note that this comes last to include integration test results.
pushes build to next server
Note that the ability to break the build when the project doesn't pass the SonarQube Quality Gate you've set up may be desirable in your situation. Unfortunately, it's not available in the current server version: 5.2. It is available in 5.1, and is should return soon.
I have a project in Jenkins (web-application with many files). There are 5 servers where I want to deploy build if it is successful: 3 production and 2 test servers. However, automatic upload is required only for the first test server (for sure only if build is not broken). To the rest servers I want to deploy manually (ideally would be separately upload to the second test server and separately for 3 production servers).
So I would like to have something like list of buttons "Upload to server #1" on the build page and on the project page, near all the plots.
However, I couldn't find anything similar which would help me on that matter. I cannot believe, is really manual publish / deployment from admin panel some kind of exotic / extraordinary operation? Probably I try to resolve my problem in wrong way?
Install Build Pipeline plugin and add "Build other projects (manual step)" in post build action of job which uploads to first test server. Once pipeline created you can run manual steps in pipeline with Pipeline view.
https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin
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.