How can I upload binaries straight to Jenkins without running a build?
For example, I want to use a customized maven, without deploying it to all of my nodes.
Is there a neat way to somehow upload this zip straight to Jenkins? Without running a build that has a publish artifacts step?
Jenkins is built for keeping the artifacts that come out of a build job. It's not built for just uploading artifacts without building.
For what you want to do, use an artifact repository server like JFrog Artifactory, Sonatype Nexus or Archiva. These are built exactly for that purpose.
Related
I have jenkins jobs that builds ios and android app and i want jenkins to upload those artifact to nexus after build is done.Is there any way to do it?
Thanks
If you are building the apps with Maven or Gradle or whatever (esp. the Android ones) a simple mvn deploy or gradle uploadArchives will do the trick. Same applies if you build the ios app with one of these tools.
In most other cases you can always do normal upload via the REST API.
Examples for the Maven and Gradle setup are in the eval guide and the examples to the Nexus book.
Use the Nexus Artifact Uploader Plugin, and set up a new job where you set a build step to Copy artifacts form another project, and a step to Upload artifact to Nexus
I have created some build configurations with snapshot and artifact dependencies (to create a build chain). The configurations are executed always on the same agent so upload of artifacts to master is not necessary.
Is that possible in TeamCity? Can I somehow avoid the upload of artifacts to master and rather pass the artifacts directly to the next build configuration in the chain?
Thanks in advance.
Martin
There is no way to disable the upload of artifacts to TeamCity, as build agents are allowed to come and go.
But since v. 8.1, TeamCity build agent caches artifacts while uploading them, so they are not re-downloaded again, when next build starts.
I have a release build that compiles and publishes the war file to Artifactory. I'd like to have a manually run parameterized build where I can choose among the release builds that it will then pull that artifact from Artifactory and deploy it. Deployment works fine, it's the choosing I'm having trouble figuring out how to do.
Is there a straightforward way to do something like this?
The closest thing I found was Promoted Build Parameter, but this doesn't seem to give me what I need as I don't know how to translate from what it gives to the file in Artifactory.
Use one script based on Artifactory REST API to fetch the needed artifacts from artifactory server.
In jenkins job, the Choice parameter can be used.
Then in the executed shell script, you pass the parameter to the script to download the artifacts.
It works fine for us.
I'm prototyping a new build system using Jenkins, Gradle, and Artifactory. There seems to be conflicting or rather overlapping features in these tools, in regards to specifying the build artifacts and their destination. I see three paths going forward:
Specify the artifact settings on the particular task in Jenkins, using the Jenkins Artifactory plugin.
Specify the artifact settings in the Gradle build scripts, using the Gradle Artifactory plugin.
Specify generic maven repo settings in the Gradle build scripts, using the standard Gradle "maven" plugin.
I see pro's and con's to all of these approaches, but nothing is missing a critical feature for our builds, as far as I can see.
To further my confusion, the Gradle Artifactory plugin wiki states:
Build Server Integration - When running Gradle builds in your
continuous integration build server, it is recommended to use one of
the Artifactory Plugins for Jenkins, TeamCity or Bamboo to configure
resolution and publishing to Artifactory with build-info capturing,
via your build server UI.
So, some questions to get the conversation going:
Does it make sense to clutter the build scripts with artifact logic? It might help to add that developer's don't deploy. Currently, I only see build artifacts being uploaded from the Jenkins task.
Does leaving all of this build logic in the task configuration expose us to issues, in the event that the CI server is down?
What about version control for artifact changes done through the CI interface?
I've seen simple Bamboo configurations that specify the build artifacts through the CI server UI, rather than the pom's. Is this just a bad build practice?
Is there a killer tool integration feature that separates one of these approaches from the other?
How useful is the build info object? Is that only available in the Jenkins Artifactory plugin and not the Gradle Artifactory plugin?
I am really hoping to hear from existing users of these tools and what pitfalls/requirements may have led them to one of the approaches above (or perhaps even a better one that I haven't considered yet).
Does it make sense to clutter the build scripts with artifact logic? It might help to add that developer's don't deploy. Currently, I only see build artifacts being uploaded from the Jenkins task.
I'd say that's the way to go. Your build server is the single point of truth, and only artifacts built in the build server should be deployed.
Does leaving all of this build logic in the task configuration expose us to issues, in the event that the CI server is down?
That one is simple - you shouldn't deploy while your CI server is down. Building on local machine might produce wrong artifacts, which shouldn't be deployed.
What about version control for artifact changes done through the CI interface?
Not sure I understood your question.
I've seen simple Bamboo configurations that specify the build artifacts through the CI server UI, rather than the pom's. Is this just a bad build practice?
This configuration ignores Maven's ability to deploy, and I am not sure I can find a good scenario to justify it. The only thing I can think of is deferred deploy, but Artifactory plugin can take care of that.
Is there a killer tool integration feature that separates one of these approaches from the other?
Now we got to the essence :)
Well, the advantage of defining what you deploy in your build script (in case of Gradle) gives you the flexibility to fine-tuning every aspect of the deployment (think about the dynamic properties you might want to add in certain cases). Another very serious advantage is that your build is source, which means it is versionable in your version control.
The advantage of defining the deployment details in the build server configuration is that the build server is the only place the deployment should occur. So, if you don't have the deployment details in your build script, you know for sure it won't be deployed standalone.
So, how can you combine between the two to get the advantages of both worlds?
Code your deployment logic in your Gradle script using the Artifactory plugin DSL. Provide details like username and password from properties, which exists on build server only.
How useful is the build info object?
Extremely useful. The information in buildInfo was harvested during the build process and the buidInfo is the only place it exists. Having this information is the only option you will be able to reproduce this build in the future.
Is that only available in the Jenkins Artifactory plugin and not the Gradle Artifactory plugin?
'artifactory' and 'artifactory-publish' Gradle plugins both generate the buildInfo object, regardless of where are they running (be it your local machine or Jenkins build server).
So I got few separated jobs in Jenkins. The first one gets the project from a Git repository, builds it and produces artifacts. And another one has to copy certificates from the first job and publish them to Artifactory (tried to make it using the Artifactory plugin). But the thing is that the Artifactory plugin's available only in the Build job, there's nothing like "Generic-Artifactory integration" in second job's configuration.
Does anyone know what are the requirements for making the plugin work in the Publish job?
You can write a small shell script leveraging Artifactory REST API and execute it in your second, non-build job.
I have done a similar thing with maven and a zip file. I have deployed a zip with a build step in maven calling a deploy:deploy-file and setting my Artifactory repository in settings.xml and deploying directly on my artifactory repository.