Here is what i am trying to achieve:
We have a SVN repository, but we dont want to promote all the changes we get via svn update!
I want to manually select each artifact and then build it via Jenkins and deploy it.
Any plugin which will allow me to do that? I dont have a simple criteria like exclude *.jar or *.xml but it is purely manual human intervention.
Thanks,
Zoom
What about making a new job with build parameters. One of the parameters could be a svn tag/branch to build/run/use, then have a build step that runs a script. In the script you can do whatever you wish with that svn tag, including a checkout and build.
Or, if you want to use pre-built artifacts from another job, you can specify links to those artifacts in the build parameters or a job name/number and have the script automatically grab them for you.
Many different ways to run a job manually :)
Related
I need a way to automate jar creation for some old releases in gitlab. I wonder if jenkins can help me or not ? And how ?
You probably must be having tags in gitlab for those releases...right. So you can create git based parametrized build which will show you all the branches/tags while doing the build...from the dropdown list you can select the required tag and it will do the creation of jar assuming you have build scripts in place.
Current scenario: Build and deployment happens in development environment and the code is checked in to GIT and the JAR file is placed in Nexus. Then a change request is raised to deploy the same to the QA environments. The CR is attached with two parameterized text files (One of which contains the nexus path and other contains website URL) which act as input for parametrized build along with selection of environment. Run deploy
Target Scenario:We want to remove the CR part and in doing so we want a file (containing parameters which were attached in CR) which when pushed to GIT, a copy-paste should happen to the parametrized Jenkins job in respective parameters and select the environment from dropdown.
What is the best way to achieve this, either by creating another Jenkins job which can read the parameters from the file or is there any other way.
P.S. We don't want to make any editing in the existing Parameterized Jenkins jobs.
Using the Jenkins GitHub Plugin, you can create a separate job with a GitHub build trigger. By adding the GitHub repo (where the parameter file is pushed) to this Jenkins job, you can process the file to get the parameters you want in order to kick off the appropriate Jenkins jobs.
For Jenkins to process the parameters, one option is to use the EnvInject Plugin. (As suggested in this answer.) Another suggestion: Extended Choice Parameter Plugin (from this answer).
I would like to share byproducts of one jenkins job, with another one that run after.
I am aware that I can set "use custom workspace", but that would merge the jobs together; which is not what I want. I just need to move few files in a location, that are read by the next job.
So far I can't find out how you actually tell Jenkins jobs to look for a specific folder; since it does not have a concept of file system, beyond what is going on in the job workspace folder.
Is there a way to access the host file system, or declare a shared folder inside jenkins (like in the main workspace folder, which contains all the other jobs?), so I can copy and read files in it, from different jobs?
Where possible I would like to avoid plugins and extras; I would like to use what is included with Jenkins base.
I realize you want to avoid plugins, but the Jenkins-y way to accomplish this is to use the Copy Artifacts plugin, which does exactly what you want.
There are a variety of problems that you may run into when trying to manage the filesystem yourself. (How do you publish to a common location when running on different build nodes? How do you handle unsuccessful builds?) This solution uses Jenkins to track builds and artifacts. In the absence of a separate artifact repository, its a lot better than trying to manage it yourself.
To use Copy Artifacts:
As a Post-Build step, choose "Archive Artifacts" in the first job and enter the path(s) to the generated files.
Then in the second job, add a "Copy Artifacts from another project" build step to grab some or all files marked as artifacts in your first job. (By default, Jenkins will re-create the paths of the generated files in the second job's workspace, which may or may not be what you want, but you can change this behavior.)
Configure the Jenkins to run a Maven build, and deploy your artifacts with "mvn clean deploy" This will push it to an "artifact server" which you probably have, or if not, need to add / configure.
Then in your downstream job, also a Maven job, you configure it to depend on the same artifact that was published in the upstream job. This will trigger a download of the artifact from the artifact server and make it available to the build.
I normally check out code to a temp folder and run composer against the folder. If it passes, I then create a tag from within said folder. In Jenkins I can kick off composer just fine, but I need Jenkins to create the tag from the workspace and not from the branch.
If this can't be done using tagging feature within Jenkins, I suppose I could use a series of Post-Build scripts.
There is an option on Jenkins to tag a particular build, which captures the workspace at that point in time.
Using the GUI, it's the Tag this build option which appears when viewing a build.
Using a URL, it's
http://my-server:portnumber/jenkins/job/my_job_name/buildnumber/tagBuild/
Is that what you meant?
I am currently triggering a new Jenkins build whenever a commit to SVN has been made. However, I would like to make another build where our database is deployed only if the Ant script deploying the database OR our SQL scripts has been changed in SVN due to a commit. Is this possible to do in Jenkins?
There is no way to do this out of the box. But you can achieve this through other means.
For the job, you only specify the SVN sources for which you would want to listen. The remaining svn sources can be added to the appropriate location using command line svn methods. Ensure that the command line execution will place and merge the existing sources that jenkins has got. You have to give the right destination options in the svn commands. I myself agree that this is not a very clean way to do, but at least there is a work around for that.
Have two jobs. The first job will be defined only on the required svn sources and you enable the poll option. This should trigger another downstream project which reads all source files. This job should not be polling svn and the actual build execution should be done here.