I am using jenkins for continuous integration. I have created seperate views like view A for server A , view B for server B etc.
Each view builds my project based on the server's environment properties.
But i could see that irrelevant upstream and downstream are getting created even when it is not created explicitly. Is there any solution for this? :(
In Jenkins,When you have projects that depend on each other, Jenkins can track which build of the upstream project is used by which build of the downstream project, by using the records created by the fingerprint support.
For this feature to work, the following conditions need to be met:
The upstream project records the fingerprints of its build artifacts The downstream project records the fingerprints of the upstream files it uses This allows Jenkins to correlate two projects.
Because of this, the upstream and downstream might be created automatically. So, in the project configuration, uncheck the option
Build Triggers
Build whenever a SNAPSHOT dependency is built
This will remove all the upstream downstream that are existing even after deleting the streaming dependency explicitly.
Upstream-Downstream relationship is created in two ways:
You trigger a build using build triggers in Post Build actions.
Fingerprinting. In this case if a file is fingerprinted in upstream jobs and is also used and fingerprinted in any other job, both the jobs develop an upstream- downstream relationship.
For the first case you can remove the build trigger to remove Upstream-Downstream relationship.
In the second case, you cannot restrict Jenkins from creating that relationship but can restrict automatic trigger of the downstream job by checking "Disable triggering of downstream projects" option under the Build configuration. This will trigger only those downstream jobs that are explicitly configured to get triggered in post build actions.
Hope this helps.
Related
I have a job that is triggered as a post-build action for dozens of other jobs. It essentially organizes and process the artifacts of those upstream jobs (using Copy Artifact Plugin), and publishes the reformatted logs, and originals, as artifacts of its own.
I want the build summary pages of an upstream job to have a link to that downstream job. From what I gather, this is not an intended use case. Conventional wisdom seems to be that if we want a link to a downstream job, we should run it as a sub-project within the Build step of the upstream job. But if I do that, I don't have the artifacts to pass to the downstream job. Catch 22.
Or is there something (even something really hacky and nasty) I can do to make this work. People want to get the processed artifacts directly from the build page.
One way (and I think the only way) to do this would be to call the Jenkins api from the downstream job to put a link to itself in the upstream job's description. But this seemed like more work than it was worth. So we just didn't do anything, and we're all fine.
the company where I work for is evaluating jenkins 2.71, in particular the pipeline and blue ocean plugins. We already tested also GoCD and we need, as in GoCD, a way for a pipeline to automatically fetch the artifacts from 2 other pipelines (taking the last successful result of each one of them), here our case.
We have these initial pipelines (build & run tests), which reflect 2 projects:
frontend, ~ 15 minutes
backend, ~10 minutes
I created a pipeline called configure (~1 minute), with e.g. a parameter called customer-name, which takes backend and frontend files and puts them together, then applies specific customer specific configurations and customizations and produces deployable artifacts. Instead of "customer-name" I could also parallelize this job to create all the artifacts for each customer at once, separated in different directories.
The next pipeline would be to deploy them on different test servers separated for each customer. This could be also part of the same configure pipeline, we still have to see how to put things together in jenkins...
Ideally, I need configure pipeline to be triggered automatically (or also on demand) after each frontend or backend success and take as input the last successful artifacts from these 2 pipelines, but not just having the last successful build, we need as dependency the git branch name.
E.g. we have:
backend branches:
master
release/2017.2
frontend braches:
master
release/2017.2
In the pipeline editor, I found a Build Triggers option and set it as follows: Build after other projects are built > Projects to watch: frontend, backend > Check Trigger only if build is stable or better in my test environment full of failures Trigger even if the build is unstable.
Searching further, I found Copy Artifact Plugin
But now the big question, how to fetch the last successful artifacts from these pipelines with the same git branch name?
Because we don't want to mix e.g. a backend build of "release/2017.2" with frontend "master", it has to find as the last successful build having the same relationship or parameter or whatever you wanna call it, in our case the association is the git branch name.
Is it possible to achieve this? If yes, how?
The copy artifact plugin seems to work in a freestyle project. Would it work in a pipeline? That's also a concern...
Thanks
Yes, the Copy Artifact plugin does work in both freestyle and pipeline projects; pipeline uses the copyArtifact function that I referenced in my comment. Note that if you go to the Pipeline Syntax link, it's kind of hidden: you have to first select "step: General Build Step" from the drop-down, then it will give you the Copy Artifact pipeline command builder.
I'm going to assume that your frontend and backend projects are built as multi-branch pipelines, as that would probably be easiest to maintain so that you don't have to keep creating new projects for every release. You can reference these projects from other projects by referencing <project name>/<branch name> (sometimes I've had to replace the / with %2f instead, I think mostly on freestyle projects). You could then set up your configure project as a parameterized build (either pipeline or freestyle), say with a string parameter of PROJECT_BRANCH_NAME. Then put in the following in your frontend/backend project pipeline scripts to trigger a build of your configure project
build job: 'configure', parameters: [[$class: 'StringParameterValue', name: 'PROJECT_BRANCH_NAME', value: ${env.BRANCH_NAME}]]
Then you should just be able to make your configure project reference the frontend/%PROJECT_BRANCH_NAME% and backend/%PROJECT_BRANCH_NAME% (or ${env.PROJECT_BRANCH_NAME} in a pipeline script) when copying the artifacts.
Also, is there a particular reason why you're evaluating specifically Jenkins 2.7? 2.7 is a year old now, and there have been a few new LTS releases since then. I'd recommend staying reasonably up-to-date unless you know there's a specific reason you want 2.7.
We are setting up a continuous delivery pipeline in Jenkins, using the build pipeline plugin.
Our deployment steps uses a proprietary deploy tool (triggered by a HTTP request from jenkins), but we need to have an additional Jenkins step for acceptance tests on the then deployed project. So our deploy tool will need to trigger the last pipeline step.
The jenkins setup for this is obvious:
For a Manually Triggered downstream build step: To add a build step
that will wait for a manual trigger:
Select the Build Pipeline Plugin, Manually Execute Downstream Project check-box
Enter the name(s) of the downstream projects in the Downstream
Project Names field. (n.b. Multiple projects can be specified by using comma, like "abc, def".)
Source: Build Pipeline Plugin
The problem is: I can't seem to find a way to trigger this downstream build through a URL.
In fact I'd need the URL in the deploy job, so I can send it to the deploy tool as a callback URL. Can anybody help?
If I understand correctly, you want to use remote access API, which to my knowledge is no different between general project or pipeline one.
Take a look here:
https://wiki.jenkins-ci.org/display/JENKINS/Remote+access+API
Submitting jobs
Jobs without parameters
You merely need to perform an HTTP POST on JENKINS_URL/job/JOBNAME/build?token=TOKEN where TOKEN is set up in the job configuration.
As stated above by #rafal S do
read a file which has list projects name for which build job has to be triggered do a curl HTTP POST on JENKINS_URL/job/${JOBNAME from the file}/build?token=TOKEN within a for loop , where for loop has list of all project names from the file you read
I have some reports that I would like to push up to Github after my main project target builds.
These reports should be pushed up whether the first project succeeds or not. Can Jenkins do either of the following:
Specify multiple tasks (like Bamboo).
Build another project after the first, even if the first fails.
Reading your comment on the other Answers I propose this solution for you Jasper
Keep you existing project that builds and generates your reports and create a new project that you might call "report uploader" which only uploads your reports to your git.
1) Main Project Build
this will build you system, run it and test it (resulting in some reports, let's call them REPORT.o)
this project might or might not fail
REPORT.o should be archived as artifacts then the build is finished
the job should always trigger the "report uploader" job - Use the parameterized build trigger plugging
make sure this job has the checkbox wait for downstream jobs (else a new job might be started and overwrite the report files)
2) Report uploader Build
this will project will take arguments from the upstream job to find the artifacts
fetch them and upload them to whatever server you like to have
The same concept is loosely described on jenkins wiki
hope this fits your need
Yes.
With Git publisher you can push to a branch and choose whether or not to only do so when the build succeeds.
There is also a post-build action where you can build other projects and an option to do so even if the build fails.
Let's say I have this situation. I have three jobs. Job number one has two manually triggered downstream jobs (deploy to test, deploy to prod for example). Something like this:
I want the deployment jobs (test-job-2, test-job-3) to require a password before they are triggered. How can I solve this with Jenkins?
The only option right now supported by the Build Pipeline Plugin is to have a manually deployed downstream job. But this job starts right after you click on it. I would like to require the user to manually enter some parameters (password for example).
Is there some workaround? I was thinking of using the Promoted Builds Plugin. So the deployment jobs would run in a "dry run mode" - just checking that we have ssh access to the server and some other basic stuff. And then in order to deploy you will have to promote the build.
This approach isn't very nice though. Build pipeline and promoted builds plugins don't interact with each other very well.
This is not exactly what you want, but I guess it would some how solve your problem.
View Job Filters
Using this feature in tandem with a security feature such as the Standard matrix based security can help you create a view that will show different jobs depending on who is logged in.
I use different Jenkins Servers to "complete the pipeline" using Build Publisher job to publish the last part of the pipeline job to the other jenkins. I then pick it up from there. Operations teams have access to the "prod" jenkins system, and developers have access to the "dev" system.