How to easily publish non-Maven artifacts from Jenkins to Bintray? - jenkins

Is there an easy way to publish non-Maven artifacts to a generic repository on Bintray from a Jenkins job? I've been reading through Deploying Maven and Gradle snapshots to OJO but that applies to Maven-compatible artifacts / Maven repositories only.
I'm aware that I could use the Bintray REST API, but that's a bit too low-level for my taste. I'm wondering if there's something for Jenkins like the Artifactory Plugin, but for use with Bintray.
The closest thing I've found so far is a Bintray REST API wrapper like this Perl module, but I don't like that either as I'd need to install the module on all Jenkins nodes then.

For Bintray, there is Bintray Java Client. We are going to release the new version, which supports file upload and signing in the following week or so.

Related

There is no AWS Codedeploy Plugin in Jenkins

I use two different Jenkins servers(tomcat jenkins) and i was trying to install a plugin for aws codedeploy.
However, I couldn't find it in the list of a Jenkins but another one has it.
Why the plugin libraries are different? even though i install them in a same way.
Also, How can i add a particular plugin in my Jenkins server?
Thank you.
Why the plugin libraries are different?
The plugin libraries shouldn't be different.
Which way did you search the plugin (jenkins gui, in the web)? Both your servers are on the same Jenkins version?
Also, How can i add a particular plugin in my Jenkins server?
I do it always via the GUI as described here: https://jenkins.io/doc/book/managing/plugins/

How to deploy delphi exe output to artifactory using jenkins

I use a script in Jenkins to build delphi projects and I want to deploy their .exe outputs to Artifactory server but I dont know how. Is there any plugin to deploy exe files to Artifactory?
Is it a good idea to deploy them to Artifactory?
The best would be using the Jenkins Artifactory plugin.
The plugin allows your build jobs to deploy artifacts automatically to Artifactory and have them linked to the build job that created them.
The support for generic (freestyle) builds is probably the most suitable one for deploying the .exe files. As part of the support for generic builds, you will be able to defined patterns for selecting which files would be deployed and to where.

Repository manager that manages binary dll files (Embedded C/C++ project artifacts) and that integrates with Jenkins

Is there any Repository manager that manages the binary dll files and also integrates well with the Jenkins?
Can Nexus be used to manage the dll files as these files are created as a part of Embedded C/C++ Projects and not sure if Nexus Artifact Manager supports/integrates well with such Projects as it mainly supports the Java projects?
Is there a way to automatically manage the upload and download of such project artifacts from Nexus/other artifact managers without the use of POM file?
Suggest in case there are other Artifact Managers that supports binary artifacts.
Artifactory can be used to store any type of binaries.
Starting with Artifactory 4.0, you can create generic repositories which allows uploading packages of any type. You will not need to upload any POM files and Artifactory will not need to calculate any metadata (for example Maven metadata).
To deploy files you can use the REST API or the UI, for example:
curl -uUSER:PASS -T file.dll http://localhost:8081/artifactory/dll-local/path/to/file.dll
If you have a certain layout you would like to use for this repository you can create a custom layout and associate it with the repository. This can be useful for automatic snapshot/integration versions cleanup and other module management tasks.
Disclaimer: I'm affiliated with Artifactory
The Nexus repository manager is java oriented, but can be used to store any files you want. Binaries of all types or even just text configuration files.
To automate the file upload process, you can use maven from command line:
mvn deploy:deploy-file -DgroupId=com.you -DartifactId=file -Dversion=1.0 -Dpackaging=exe -Dfile=c:\out\file.exe -Durl=http://yourserver/nexus/content/repositories/releases -DrepositoryId=releases
Then, to get the file, you should be able to get it directly with the following URL:
wget http://yourserver/nexus/content/repositories/releases/com/you/file/1.0/file-1.0.exe
This is a simple approach to using Nexus as a general artifact repository.
I hope this helps.
The open source version of Nexus (Nexus OSS) is supports many repository formats out of the box including Maven, NuGet, NPM, RubyGems and others. Nexus just runs on Java (e.g. like Jenkins). It is not Java only...
Depending on how you plan to get the DLL files from the repository, different formats might be more or less suited to your usage. You could even use a custom format, but then you rely custom tools.
The scenarios I have seen at many customers are
using a Maven repo and pulling the files in either in a Maven build together with the Maven NAR Plugin (used for native development with C/C++)
using a Maven repo and pulling via plan HTTP GET calls using your scripting language/build tool of choice
using NuGet format and store the DLLs in NuGet packages in the repo and using nuget to retrieve them for the projects
All of these work well.

Jenkins + Tycho: propagating update sites

I'm wondering if there is an easy way to "publish" p2 update sites in Jenkins (built with Tycho) so that they can easily be accessed in downstreams jobs? Currently I'm doing it semi-manually using Jenkins support for copying artifacts between jobs, and then specifying a repository-mirror element in a job-specific settings.xml which refers to the artifacts copied into the job, but this is all a little tricky and requires configuring jobs and build settings in a number of different places.
Is there any nicer way short of using an external solution such as Artifactory?
The only solution involving a repository manager that I am aware of is to use a Nexus and the Unzip Plug-in. (Disclaimer: The Unzip Plug-in is provided by the Tycho project, of which I am a committer.)
With such a setup, you could have one job deploy an update site to Nexus, and the next job use the update site via the unzip URL of the deployed site. Example: If the site was deployed under the GAV project.abc:site:1.0.0-SNAPSHOT, you could then access it via http://<nexus>/content/repositories/<unzip-repo-name>/project/abc/site/1.0.0-SNAPSHOT/site-1.0.0-SNAPSHOT-unzip/.
Note that you are slightly less flexible with such a setup that with what you have set up now: You need to have a version number for what your upstream project is building, so this may become tricky if you have multiple feature branches developing towards the same release version.
If you don't need this, you have the benefit of getting a portable build of your downstream project, i.e. developers build the project in the same way as your Jenkins does.

creating a local repository in Artifactory

I've just started installing Jenkins along with Artifactory and Ivy at our company.
Jenkins will be calling our ant build scripts and these scripts will then turn to Ivy to retrieve jars from the local repo (only).
We would like to have 2 local repositories : 1 for our local artifacts and 1 for 3rd party jars.
Our intent is to make sure developers retrieve only 3rd party jars that have been "approved" by admin in Artifactory.
The build scripts would then fetch from the local repository.
So my questiona are :
How do we setup a local repository to include the built artifacts?
How are 3rd party jars retrieved by Artifactory if it has no access to internet?
Is there a better way of doing this?
I'm not sure if I'm missing something, but setting up the local repository for your build artifacts should be straightforward, just follow the instructions in the Artifactory docs.
You would need to configure your build system to publish new artifacts to Artifactory. This is also straightforward if you're using a standard dependency management tool like Maven or Ivy, and is covered in the Artifactory docs.
Keeping a separate repo for 3rd party JARs is also not too hard; at my company we do this by submitting the JARs to source control, which triggers a build in our CI system that publishes the JARs to Artifactory.
If you want to give more details of your build and CI setup I can add additional guidelines.

Resources