• Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • None
    • Deployments, Maven
    • None
    • 2
    • 2
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Allow maven artifacts to be treated as Bamboo artifacts in deployment projects

            [BAM-13345] Deploy maven artifacts in deployment projects

            @robert_hall1 , the reference plugin actually does exactly what you are looking for. It delegates to Maven for the configuration of things like a repository URL and credentials. Generally you would specify these things in your settings.xml. It assumes that since you published the artifact using Maven, you would want to use the same configuration for accessing it. Feel free to contact me directly if you have any questions.

            David Ehringer added a comment - @robert_hall1 , the reference plugin actually does exactly what you are looking for. It delegates to Maven for the configuration of things like a repository URL and credentials. Generally you would specify these things in your settings.xml . It assumes that since you published the artifact using Maven, you would want to use the same configuration for accessing it. Feel free to contact me directly if you have any questions.

            I just wanted to share the use-case that my team would have for deploying maven artifacts.

            Our current release process involves the following steps:

            1. Update the pom from a SNAPSHOT to a non-SNAPSHOT version
            2. Build the artifact
            3. Commit and tag the pom changes
            4. Deploy the artifact (using mvn deploy, this will send the artifact to our private Nexus instance)
            5. Manually download the produced artifact from Nexus and deploy it to the test server
            6. Validate the artifact
            7. Deploy to additional servers as part of testing the release - eventually it will be deployed by another team to production

            I can think of a few possible ways to simplify things

            • Automatically build a new "Release" for a "Deployment Plan" after our release job finishes
            • Allow Releases not to contain any artifacts, but allow the Release name to be used in the deployment tasks
            • Allow a release job to automatically create a Release under the Deployment plan based on the shared artifact

            Michael Martz added a comment - I just wanted to share the use-case that my team would have for deploying maven artifacts. Our current release process involves the following steps: Update the pom from a SNAPSHOT to a non-SNAPSHOT version Build the artifact Commit and tag the pom changes Deploy the artifact (using mvn deploy, this will send the artifact to our private Nexus instance) Manually download the produced artifact from Nexus and deploy it to the test server Validate the artifact Deploy to additional servers as part of testing the release - eventually it will be deployed by another team to production I can think of a few possible ways to simplify things Automatically build a new "Release" for a "Deployment Plan" after our release job finishes Allow Releases not to contain any artifacts, but allow the Release name to be used in the deployment tasks Allow a release job to automatically create a Release under the Deployment plan based on the shared artifact

            We've started using Go (http://www.thoughtworks.com/products/docs/go/current/help/) - how this is solved is our full continuous delivery process is housed within this tool. We then have a final stage that just assembles the barista artifact and pushes this to the sparrow library - using either snapshots or release builds. We've found that maven and continuous delivery don't work together so there is a bigger context to this issue that we'd have to solve.

            James Sammut added a comment - We've started using Go ( http://www.thoughtworks.com/products/docs/go/current/help/ ) - how this is solved is our full continuous delivery process is housed within this tool. We then have a final stage that just assembles the barista artifact and pushes this to the sparrow library - using either snapshots or release builds. We've found that maven and continuous delivery don't work together so there is a bigger context to this issue that we'd have to solve.

            I've looked into the plugin mentioned in the comments, but with the manual settings for maven coordinates, I saw no way to specify the Nexus repository url, username, password etc. My current use case is I have Bamboo builds that deploy war file artifacts to a Nexus repository. I then want to have a deploy build extract those war files from the Nexus repository and deploy to an environment.

            Robert Hall added a comment - I've looked into the plugin mentioned in the comments, but with the manual settings for maven coordinates, I saw no way to specify the Nexus repository url, username, password etc. My current use case is I have Bamboo builds that deploy war file artifacts to a Nexus repository. I then want to have a deploy build extract those war files from the Nexus repository and deploy to an environment.

            This plugin, https://marketplace.atlassian.com/plugins/org.gaptap.bamboo.maven.maven-artifact-download-plugin, may help with many of the use cases described here.

            David Ehringer added a comment - This plugin, https://marketplace.atlassian.com/plugins/org.gaptap.bamboo.maven.maven-artifact-download-plugin , may help with many of the use cases described here.

            We're using Artifactory as our binary artifact server. We want to be able to deploy maven artifacts to Artifactory within a plan and download the maven artifacts within a deployment task. That would allow us to manage all artifacts within Artifactory. At the moment, we need to store them as Bamboo artifacts as well.

            Christoph Feddersen added a comment - We're using Artifactory as our binary artifact server. We want to be able to deploy maven artifacts to Artifactory within a plan and download the maven artifacts within a deployment task. That would allow us to manage all artifacts within Artifactory. At the moment, we need to store them as Bamboo artifacts as well.

            We use maven to manage our release artifacts. I would love for the release to be based on the maven artifact version. I could then use the product to automate our deployment needs as well as provide all the meta data required for a release.

            The release creation couldd use the maven release plugin to produce the release.

            This lack of maven support currently is stopping me purchasing this product.
            Reading threads on this I am assuming we'll have to write our own plugin to support this?

            James Sammut added a comment - We use maven to manage our release artifacts. I would love for the release to be based on the maven artifact version. I could then use the product to automate our deployment needs as well as provide all the meta data required for a release. The release creation couldd use the maven release plugin to produce the release. This lack of maven support currently is stopping me purchasing this product. Reading threads on this I am assuming we'll have to write our own plugin to support this?

            Experimenting with potential solutions to help with the scenarios I deal with everyday, I created a "maven-artifact-download" plugin. While it isn't potentially as nice as something natively built into Bamboo, it might help some people now. If people find it useful, I'll get it published to the Marketplace but in the meantime you can find it at https://bitbucket.org/dehringer/bamboo-maven-artifact-download-plugin/downloads.

            You can pass the POM(s) out of your build Plan as artifacts and they can be used to automatically figure out what needs to be downloaded. This keeps the artifacts managed by Bamboo to a minimum with the POM really representing metadata. Manually setting the Maven coordinates can also be done if you don't have the POM available or need to fetch other artifacts.

            Expanding upon what I explain above for our use case, we publish all artifacts to an external artifact repo. We often use Maven profiles to have artifacts to different repos (e.g. different business units have separate repos). Along with the primary artifact (e.g. JAR, WAR), we also often publish secondary artifact using the maven-assembly-plugin that contain additional things that aren't bundled in the primary artifact such as DDL, scripts, configuration, smoke tests, etc. We need to be able to download those as well in Deployment Projects.

            David Ehringer added a comment - Experimenting with potential solutions to help with the scenarios I deal with everyday, I created a "maven-artifact-download" plugin. While it isn't potentially as nice as something natively built into Bamboo, it might help some people now. If people find it useful, I'll get it published to the Marketplace but in the meantime you can find it at https://bitbucket.org/dehringer/bamboo-maven-artifact-download-plugin/downloads . You can pass the POM(s) out of your build Plan as artifacts and they can be used to automatically figure out what needs to be downloaded. This keeps the artifacts managed by Bamboo to a minimum with the POM really representing metadata. Manually setting the Maven coordinates can also be done if you don't have the POM available or need to fetch other artifacts. Expanding upon what I explain above for our use case, we publish all artifacts to an external artifact repo. We often use Maven profiles to have artifacts to different repos (e.g. different business units have separate repos). Along with the primary artifact (e.g. JAR, WAR), we also often publish secondary artifact using the maven-assembly-plugin that contain additional things that aren't bundled in the primary artifact such as DDL, scripts, configuration, smoke tests, etc. We need to be able to download those as well in Deployment Projects.

            All our applications are built using maven and deployed to a maven repo which is, in our case, Nexus. When we release them, we also use a custom goal that verifies in Jira that the version exists and that there is at least on issue fixed by this version. This is to ensure that we have a consistency between our maven releases repo and Jira.

            What we would like as feature in deployment projects would be the ability to specify the groupId, artifactId and the version to deploy. That would be great if there would be a way to load versions (or releases) from Jira instead to configuring them in Bamboo.

            I'm aware that there is some workarounds for our main use case, but having Bamboo integrate them would be very nice and would take the deployment projects feature a step ahead!

            Sebastien Boudreau added a comment - All our applications are built using maven and deployed to a maven repo which is, in our case, Nexus. When we release them, we also use a custom goal that verifies in Jira that the version exists and that there is at least on issue fixed by this version. This is to ensure that we have a consistency between our maven releases repo and Jira. What we would like as feature in deployment projects would be the ability to specify the groupId, artifactId and the version to deploy. That would be great if there would be a way to load versions (or releases) from Jira instead to configuring them in Bamboo. I'm aware that there is some workarounds for our main use case, but having Bamboo integrate them would be very nice and would take the deployment projects feature a step ahead!

            @David - If you want an interim workaround. We parse our build output to find the URLs of the uploaded Maven artifacts, generate a JSON document with the URLs and then attach it to the build as an artifact. You can then use this file in your deployment tasks.

            Telstra Automation Engineering added a comment - @David - If you want an interim workaround. We parse our build output to find the URLs of the uploaded Maven artifacts, generate a JSON document with the URLs and then attach it to the build as an artifact. You can then use this file in your deployment tasks.

              Unassigned Unassigned
              jdumay James Dumay
              Votes:
              80 Vote for this issue
              Watchers:
              56 Start watching this issue

                Created:
                Updated: