TeamCity has a feature which will publish the Build Information to artifactory always.(by default). If we check that publish build info option(in step 3 - i'm using gradle as Runner), The published information will be recorded in Artifactory so that, we can trace back to the build which produced the artifact.
Now i want to disable publishing build information if the build is person build. How to achieve this?
Thanks.
This isn't possible without customizing either the TeamCity Artifactory plugin or the Gradle Artifactory plugin.
Build Info descriptor deployment is currently decided upon using a boolean variable, but customizing either plugin to do what you need should be fairly easy.
Related
I cannot find in gradle docs which artifacts are uploaded by default. Is it so, that only compilation artifacts are uploaded? I have a case where I'm left with multiple jars in workspace after build process and I wanted to make sure that no garbage is uploaded.
I found info that in case of multiple artifacts I can define addFilter() but what about main artifact upload? How gradle determines which jar is uploaded by default?
I'd appreciate clear information and if someone could point me to documentation that I missed.
I cannot find in gradle docs which artifacts are uploaded by default
Gradle does not upload anything for you. You must configure whatever publishing plugin you are using with the artifacts you want published.
The official publishing plugins are:
Maven Publish
Maven Plugin (deprecated)
Neither of these plugins publish anything by default.
I have a case where I'm left with multiple jars in workspace after build process
This is normal. However, if you are seeing artifacts that should not created, then you'll need to audit your Gradle build to see how that artifact is being created and disable it if needed.
There is (1) official Gradle plugin that I am aware of that does configure the above plugins to publish an artifact. This is documented on at the very bottom here: https://docs.gradle.org/current/userguide/java_gradle_plugin.html
I'm in the latter stages of setting up a CI environment for my project. I'm using Maven, Jenkins and Artifactory Pro and can successfully build my project and deploy it's artifacts to Artifactory. I have also written a bash script to retrieve the resulting artifacts of a specific build from Artifactory and copy them somewhere.
The main part I'm missing right now is automated versioning. I've looked at enabling Artifactory release management, which is really cool, but involves the rebuilding of the project. I'm really trying to follow the mantra of 'Build Once, Deploy Anywhere', so any rebuilding is a no-no.
My question boils down to: Is there an automated way (either with one of the aforementioned tools, or a plugin) to handle versioning, without rebuilding an artifact?
Artifactory Pro allows you to easily extend Artifactory's behavior with your own plugins written in groovy. (https://www.jfrog.com/confluence/display/RTF/User+Plugins)
You can find here, an example of Promote extension, that will change your artifacts versions without the needs of new build.
You can find more usefully examples in the GitHub "artifactory-user-plugins" repository.
Actually I see two alternatives how can I deploy my project to NEXUS:
Configure distributionManagement and deploy-plugin in pom.xml. That in jenkins I should only call mvn deploy and my project will be deployed to the environment
Create in Jenkins Post-build Actions -> Deploy artifacts to maven repository, where I can set repository URL, repository ID and so on
Question
What is pros and cons of each approach comparing with one another?
If you are configuring the deployment in Jenkins build configuration you are doing two things
you are separating the deployment from the project itself and therefore potentially can have different deployments for the same project
you remove the deployment setup from your version control setup/your source code
If you are leaving it in the pom using the default Maven setup you can run deployment of the project without modification from the commandline on any machine that has the credentials set up correctly. This can greatly help wit troubleshooting and it makes the setup independent of whatever CI server you use.
Both approaches as well as more custom setups like using the Artifactory Build Integration or the Nexus Staging Maven Plugin usage are fine. It will mostly depend on what you are aiming to achieve.
Personally I believe that the configuration should not be isolated to Jenkins and should remain with the project in the pom. But that is just my 2c.
Thanks for adding the Artifactory tag, now I can give you one more option - Artifactory Build Integration. With Artifactory Jenkins plugin you can configure your deployment options (target repository, whether or not you want to deploy build information, environment variables and custom properties etc.) without polluting your developers pom with ci-eyes only information.
I was wondering if there is a Hudson/Jenkins plugin that ties repository artifacts to the build that created them? I was looking at the question "remove artifacts from nexus repository" and thinking that deleting a build in Jenkins should also offer the option to remove the artifacts the build created.
We are currently running Jenkins 1.447 and the Nexus Open Source 1.9.2.3. Our Jenkins builds create artifacts in our Nexus repository using the maven deploy goal. I appears that once those artifacts have been deployed, there is no similarly automated mechanism to remove them. We would like to tie the Jenkins build to its Nexus artifacts. I figure if we have decided to remove the build from Jenkins, we have no use for the build and therefore, have no need to store the artifacts for that build either. We would like deleting the build to trigger deleting the Nexus artifacts.
If there's nothing available I figure I could start writing something, but I wanted to check and see how others handle this.
you can use the REST API from Nexus to build your own Jenkins Plugin that does that Job for you. You could store the Jenkins Build Job number using the Nexus custom-metadata plugin. Once the build is deleted you can have your custom Jenkins Plugin delete all artifacts in Nexus that have that build number in their metadate. I had a similar Problem and wrote a custom Jenkins Plugin. Have a look at the tutorial and the source code on github. It should be pretty straight forward.
Tutorial:
http://blog.codecentric.de/en/2012/08/tutorial-create-a-jenkins-plugin-to-integrate-jenkins-and-nexus-repository/
Sourcecode:
https://github.com/marcelbirkner/nexus-metadata-plugin/
You can purge artifacts from a local repository via the maven-dependency-plugin.
If you have a release it does not make sense to number it based on the numbers of the build server. The usual use case is to use SNAPSHOT's for exactly this purpose. Furthermore the usual use case is to delete SNAPSHOT's based on a scheduled task after a time from Nexus but releases will never be deleted from Nexus.
Since you know the name of the release, you could build a custom job or trigger to use a wget command to delete the artifact from the nexus repository.
As the proper user in Nexus you do have the ability to delete release artifacts, not just SNAPSHOTS.
We have a Build that compiles and creates an artifact. Then we have another Build that uses the last Compile build and Deploys it to the proper environment. Once that is complete, I have to go and Tag the build in TC that it was pushed to the environment. Is there a way that I can tag the Compile Build that is was deployed using the Deploy Build?
I'm not aware of an easy way to do this (i.e. through a TeamCity configuration setting) but you probably could accomplish this using the REST API from your build script.
If you are using TeamCity 6 or above because you have a build dependency chain from the Deployment Build to the Main Build either through artifact dependencies, snapshot dependencies or both you can just tag your Deployment Build. This is because the UI will show you a tree view of the dependencies that the deployment used and you can navigate to the actual build.
One thing you can do, and in my opinion should do, is to tag your source control from TeamCity if you are using a source control that supports tagging/labelling. You should probably set your Deployment Build up with a snapshot dependency as well as the artifact dependency, especially if your build files are in the same repository. On your Main Build you should get TeamCity to label your repository on a successful build with something like "build-1.2.3.4". Then on your Deployment Build you should get it to label the repository after a successful build with "deployed-1.2.3.4". If you deploy to different environments then you can get it to label the repository accordingly.