We have a project where I upload the artifacts to a nexus repository using ant and ivy. Things have gone smooth for a long time, but now we must deploy the same artifact twice (because we are generating the same product for windows and mac). The code of the application is the same, it just changes the packaging. I have configured the deploy process to use a maven classifier. The problem is that the uploads are done from 2 different machines because each one has the appropiate build environment for the destination platform.
So, the first deploy is done right and it uploads:
myproduct-1.0.pom
myproduct-1.0-mac.zip
When I try to deploy the windows artifact, that will deploy
myproduct-1.0.pom
myproduct-1.0-win32.msi
It fails because the repository policy does not allow redeploying (and it should stay that way), so trying to deploy a new pom file for the same artifact and version fails, even if the pom contents are the same.
Also it is possible that in the future we have a similar problem, deploying various artifacts of the same product and version but different classifier from the different machine but in different build processes.
Is it possible to tell nexus to not fail if when deploying a classified artifact with a pom, does not fail if the same pom file already exists in the repository? If it is not possible, I understand that the only way to deploy various artifacts with different classifiers is to deploy them all at the same time. Is it true?
In the end, I created a task that deployed just the pom without any classifier, and modified the deploy of the windows & mac artifacts to just deploy the packages but not the pom:
deploy pom without classifier
deploy mac artifact with classifier (mac)
deploy win artficat with classifier (win32)
Nexus doesn't complain when deploying the artifact without deploying a pom file at the same time when I thought I would complain.
I feel it's a dirty trick, but it works :)
Related
Build process of java code is currently generating artifacts with name having no version number.
For ex: serial-framework-SNAPSHOT.jar
We are currently in build phase of CI/CD pipeline
All the artifacts generated through maven build has no version number for back-end services, in build phase of CI/CD pipeline
Dependent artifacts that are required to build a specific jar are only stored in JFrog artifactory
1)
Does it require versioning of artifacts for Build/QA/prod phase of CI/CD pipeline?
2)
Does it require to store every artifact in JFrog artifactory? Because only dependent artifacts that are required by pom.xml during maven build are stored in JFrog
The versioning was well explained in the first answer by snukone.Note the below points which might be helpful regarding versioning
For development always follow the version as “versionNumber-SNAPSHOT “(capital letters)
Eg:- 1.0 -SNAPSHOT
2) For test/prod branch follow the version as “versionNumber-RELEASE”
Eg:- 1.0 – RELEASE
a) Snapshots are mutable, so they are used for development purpose.
b) Releases are immutable. Once committed we cannot override the artifact in the
artifactory. So releases are used for higher environments.
c) Snapshots capture a work in progress and are used during development. A Snapshot artifact has both a version number such as “1.3.0” or “1.3” and a timestamp. For example, a snapshot artifact for commons-lang 1.3.0 might have the name commons-lang-1.3.0-20090314.182342-1.jar
So in your case if you are using "serial-framework-SNAPSHOT" it will store as "serial-framework-version-timestamp.jar" in your artifactory.
Similarly if you are using "serial-framework-RELEASE" it will store as "serial-framework-version.jar" in your artifactory.
How versioning helps:
Versioning helps in case you want to restore an older version of your application (due to bugs that are heavily decreasing performance in production)
If you are running integrationtests on api or ui level, you can specify which versions are fitting together (ie via contract testing: https://github.com/pact-foundation/pact_broker)
Default cleaning processes helps you to prevent your artifactory from huge storage usage
Storing every artifact or not?
My personal experience: Just store the artifacts which are dependencies to other artifacts. Like Libs for example. If you are working with Docker Container you should think about to version the Docker images which you are producing on every build.
I am using Free Style Projects (in Jenkins) to schedule a regression test.
1. Get Source From BitBucket
2. Execute Windows Batch Command.
Earlier we are allowed to upload the jar files in Bitbucket. So we did not face any issue. Now Presently due to some changes in the process, we are not allowed to upload binaries which is affecting to upload jars in the Bitbucket.
Now, They gave given the artifactory url to set up for Maven. But we don't have any Maven projects.
It seems that artifactory is getting populated when it is hosted in the local. But we wanted to use the artifactory which is shared..
Can any one let me know the set up for free style project and the artifactory hosted in other machine and we have only URL.
Thanks
Here is documentation:
https://www.jfrog.com/confluence/display/RTF/Jenkins+Artifactory+Plug-in
I recommend to use Maven Project.
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.
I don't like when it comes to release my projects on production server.. May be i just don't have enough experience, nobody taught me how to do this in a right way.
For now i have several repos with scala (on top of spray). I have everything to build and run this projects on my local machine (of course, i develop them). So installed jenkins on my production server in order to sync from git, build and run. It works for now but i don't like it, because i need to install jenkins on every machine i want to have run my projects. What if i want to show my project to my friend in cafe?
So i've come with idea: what if i run tests before building app, make portable build (e.q. with sbt native packager) and save it on remote server "release server". That server just keeps these ready to be launched apps.
Then i go to production server, run bash script that downloads executables from release server and runs my project on a machine
In future i want to:
download and run projects inside docker containers.
keep ready to be served static files for frontend. Run docker
container with nginx and linked volume with static files
I heard about nexus (http://www.sonatype.org/nexus/), that artist use to save their songs, images, so on. I believe there should be open source projects that expose idea like mine
Any help is appreciated!
A common anti-pattern, in my opinion, is to build the software every time you perform a deployment.You are best advised to separate the process of build from the act of deployment by introducing a binary repository manager (you've mentioned on such example, nexus).
Best Practice - Using a Repository Manager
Binary repository manager
How can I automatically deploy a war from Nexus to Tomcat?
Only successfully tests builds get pushed to the repository, so you can treat each successful build as a mini-release. A by-product of this is that your production server does not have to have all the build software pre-installed (like, Jenkins, ANT , Maven, etc).
It should be noted that modern repository managers like Nexus and Artifactory now support Docker registries too, so that you use these for deploying docker images too.
Update
A related chef question, a technology where there is no intermediate binary file (like a jar). In this case the software is still "released" by creating a tar distribution stored in the repo.
chef cookbook delivery - chef server vs. artifactory + berkshelf
Trying to deploy on a staging repository leads on the maven side to
400 , ReasonPhrase:Bad Request
and the server log contains
Staging of Repository within profile ID='X' is not yet started!
It makes no difference using maven-deploy-plugin or maven-release-plugin. All three leads to the error from above.
My deployment user has (admin) rights to deploy to every staging profile.
maven-release-plugin:
mvn release:stage -DstagingRepository=nexus::default::http://localhost:8081/nexus/service/local/staging/deploy/maven2
If you doesn't use versions with the maven-release-plugin like SNAPSHOT qualifier and similar, nexus-staging-plugin works fine.
What did I miss?
Staging of snapshot versions is not allowed, you need to use release versions.
At first glance you might think that this could be done by having Nexus rewrite the pom files and rename the artifacts. But it's not that simple, the version number is often embedded in the artifacts themselves. This is particularly true of assembled artifacts such as war/ear files, you'll find the version numbers inside contained artifacts, and inside configuration files within the artifact. Even if these could be rewritten by Nexus changing the version numbers potentially changes the behavior of the artifacts. In any case, Nexus will not change staged artifacts, any changes made could potentially lead to regressions. Staged artifacts (like all artifacts deployed to Nexus) are immutable.
Consequentially, you need to use a release version when staging.