I have curren Jenkins jobs:
1. Poll -- Retrieve Latest Tag from SVN
2. Create release and archive it
3. Manual trigger -- Deploy artifact to test environment
So 1. retrieves regularly the latest SVN tag (if created), 2. builds the release (.ear files and DB scripts) and stores the artifacts with the "Archive the artifacts" post-build job, and 3. is a manual trigger job where you actually would have to press a button to deploy the release to test environment
My question is, is it possible in build 3. to somehow "select" the desired artifact? Or is it only possible to deploy the latest workspace? Thanks!
Here is a detailed explanation how to select a specific build for deployment
How to promote a specific build number from another job in Jenkins?
In short, you need to combine Copy Artifacts plugin with Promotions concept
Related
I have two Jenkins tasks, one that builds and promotes the successful build, and another task that deploys those promoted builds. I'm using two plugins to accomplish this task, Copy Artifact Plugin and promoted builds.
The job that I have to build the code is a very standard one, I go to the git repository every minute to check for any changes, and if there are any changes I just Invoque Gradle Script on the Build step and select Use Gradle Wrapper box and everything builds without a problem. The only custom part of this build task is that I'm using promoted builds plugin, which works great and have a very standard configuration as well.
Build Configuration
I'm happy with my Build task, but I have a problem with my Deploy task. In my deploy task I want to select which promoted build I want to deploy, but I can't deploy the selected promoted build.
In my Deploy task I tick the This project is parameterised box and I selected the Promoted Build Parameter.
Promoted Build Parameter Configuration
The configuration looks ok, when I run the Deploy task I can select which build I want to deploy.
Select build to be deployed
The problem that I have is when I select Copy artifacts from another project. In Which build I select Specified by a build parameter and for the Parameter Name I selected the same name I gave to the Promoted Build Parameter
Copy artifacts from another project Configuration
But when I run this Deploy task I get this error: ERROR: Unable to find a build for artifact copy from: Aurora.
BUT if I change the Which build part to Copy from WORKSPACE of latest completed build everything works fine.
Working Configuration
What am I doing wrong in this configuration?
I was able to solve this problem, I don't think it was the cleanest way of doing it but at the end it worked. In the Build task I left everything as it was, I only added a Post-Build Action to Archive the artifacts.
Post Build Action
In the Deploy task I needed to change a bit more stuff. In my Deploy task I tick the This project is parameterised box and I selected the Promoted Build Parameter, the configuration for this step is a very standard one, I just selected the Build project and the rest is automatic. This step enables me to select which promoted build I want to deploy, but this is where the big problem resides. The value that this "step" returns is something like this https://site.name.com/job/ProjectName/137/.
The problem that this create is in Copy artifacts from another project. I need a build number, but I only have that URL, so the solution that I found was to get the build number from that URL, inject that number as a local variable and use that local variable in the next steps.
Build steps
With this solution I'm able to deploy only the promoted build.
I have a pending changelist that I want to test in the build on our Jenkins server. I tried to do this using a P4 label but syncing to the label does not pick up my pending changelist.
Is there any way to do this with Jenkins SCM configuration?
In general, unless you have some very special circumstances, no other workspace can sync your pending changelist's changes, because they exist ONLY on your own workstation, not on the server. The server knows the names of the files in your pending changelist, but not their contents.
To make your changes accessible to the automated build tools, there are generally two approaches:
You can shelve the changes, then instruct the build tool to build from the shelf, or
You can check your changes into a development branch, then instruct the build tool to build the branch.
Or, of course, you could check your changes into the mainline, and have the build tools build them normally, but I'm guessing from your question you don't want to do that.
You can use the P4 Plugin. Follow the below steps
Create a Jenkins Job
Select checkbox: This project is parameterized
Add parameter name as Changelist
For the first step of build, select the option perforce unshelve and use ${changelist} as Changelist and resolve type as per your requirement
Under Build Trigger, select Trigger builds remotely (e.g., from scripts)
To trigger the build:
Shelve the Changelist
Trigger build with URL http://jenkinurl/projectname/buildWithParam?changelist=< shelved_cl >
I have two jobs in Jenkins. First of the name “Build” and the second of the name “Deploy to test environment”. In the first job, tester sets promotion manually, and then only promoted builds can be deployed. In second job I added “Promoted Build Parameter” which generates combobox with promoted builds but I can’t connect the value of this parameter with “Copy artifact from another project” build step.
So how can I copy artifacts from the selected promoted build?
In your deploy project:
Configure a Promoted Build Parameter named (for example) PromotedBuild
Configure Copy artifacts from another project to Specific build with Build number as ${PromotedBuild_NUMBER}
Also, if you want to trigger the deploy project from your build project, you can do this:
In your promotion process of your build project add Trigger parameterized build on other projects with a Predefined parameter of PromotedBuild_NUMBER=$PROMOTED_NUMBER.
In Jenkins, I have a "Build" job setup to poll my git repo and automatically build on change. Then, I have separate "Deploy to DEV", "Deploy to QA", etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.
However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it's possible the artifact could be incompatible between versions. So, it's ideal that I ensure that the build and deploy jobs are run using the same git checkout.
Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don't see any options or plugins that do this.
Any ideas on how to simplify this configuration?
You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.
The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like "LatestSuccessfulBuild") at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.
I have a maven job in jenkins. Normally at the end of the build the artifacts will be deployed to artifactory via jenkins post build action.
But if I make a release build I get an error from jenkins in this case.
So, is there a possiblity to avoid deploying the artifacts at the end of a release build.
Let me precise the error. The maven goals are 'clean install'. I need the post action for deploying to artifactory by a 'normal' job. If I make a release of this artifact via the M2 Release Plugin the deploying of the relased artifacts will be done by the M2 Release Plugin itself. But at the end of the job the post action tries to deploy artifact with the old SNAPSHOT version which is not allowed by artifactory.
Jenkins M2 release plugin (used maven-release-plugin of Maven). If you have created a Maven job (instead of a Free Style), then in M2 Release section in job's configuration, you'll see the goals are:
-Dresume=false release:prepare release:perform
If you replace it with the following M2 release plugin won't call deploy goal which is initiated by release:perform goal by default.
-Dresume=false release:prepare release:perform -Darguments="-Dmaven.deploy.skip=true"
In my case, I didn't want the artifacts to go to Artifactory as soon as release:perform and release:prepare goals were completed, so the above helped. But, even though Jenkins job has a Post Build action as "Deploy to Artifactory" to either snapshot or release repositories (depending upon what kind of build you have aka automated/manually run build job OR by running Perform Maven Release ), it never called the post build action.
This can be good in the sense, now I can call deployment using the generated release artifacts in an environment and if the deployment/some IT tests are successful, then I can upload the artifacts to Artifactory. Downside is, what if your deployment depends upon fetching the new artifact from Artifactory/Nexus (i.e. somewhere in deploy script's logic) then you can't have that working until you copy artifacts from one job to another child job.
Apart from that, maven deploy goal requires valid / settings in either settings.xml or pom.xml where the you specify for each of the above sections, which are defined under section, must match with the value of section defined in setting.xml/pom.xml.
One can defined / set the value of section to use a non-release repository which is higher in order (for artifact resolution) than a snapshot repository i.e. use libs-alpha-local or libs-stage-local and then let maven deploy goal deploy the artifacts to Artifactory/Nexus.
Later, upon successful deployments to higher environments (like QA/PRE etc), you can move the artifact from alpha/stage to libs-release-local.
IS_M2RELEASEBUILD Boolean variable which comes with M2 Release plugin can be used in a conditional step to deploy here or there or not at all.
In the configuration of the 'Maven release build' you can set in the advanced mode a 'Release environment variable' (default is IS_M2RELEASEBUILD). Later in the post-bild-action 'publish artifacts' you can check if this environment variable is set and then the deploying is skipped.
I'm thinking you may want to create a separate jenkins job just for your release builds. And under post build action to run different set of maven commands just to package the artificat and not install it to the artifactory. That being said if other applications depends on that artifact you do not want to release. This may be causing versioning problems.
You should take a look at Artifactory Jenkins plugin. 1. It deploys with errors. 2. It has built in release functionality. 3. It will provide you with unique buildInfo functionality for saving build information tougher with artifacts in Artifactory, https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin
If I can assume you're using the M2 Release Plugin, then there's another issue.
Skipping the deployment after a release would be an unnecessary workaround, since I've seen this work. You should try to fix this by the root cause.
It would help if you could provide more info about the error.