Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11426

Add checkbox to maven 2/3 configuration to archive the maven snapshots used for the build.

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • maven-plugin
    • None

      SNAPSHOTs I find to be one of the biggest pains to deal with in maven. One major part of that is that you can not rebuild a build that was built a week ago because the SNAPSHOTs have changed since then and it is hard to track which SNAPSHOT was used for which build. Release level artifacts are not a problem since they do not change.

      Add to the maven jenkins plugin the ability to archive the SNAPSHOTs (transitive dependencies included) used to build that build.

          [JENKINS-11426] Add checkbox to maven 2/3 configuration to archive the maven snapshots used for the build.

          kutzi added a comment - - edited

          That could really be a loooot of jars to archive. Plus - if I understand you correctly - you not only want the ability to archive the snapshot, but also the rebuild based on the archived artifacts instead of the ones from the maven repository, right?

          IMHO, this is not very likely to be implemented (unless you do it yourself and created a pull request) and also to be honest not a very desirable feature, too. This is basically working against everything what snapshots are supposed to be. If you're really concerned about reproducability of builds, you should only use released versions!

          And BTW: you can track which snapshots were used for old builds by checking Jenkins' fingerprints.

          kutzi added a comment - - edited That could really be a loooot of jars to archive. Plus - if I understand you correctly - you not only want the ability to archive the snapshot, but also the rebuild based on the archived artifacts instead of the ones from the maven repository, right? IMHO, this is not very likely to be implemented (unless you do it yourself and created a pull request) and also to be honest not a very desirable feature, too. This is basically working against everything what snapshots are supposed to be. If you're really concerned about reproducability of builds, you should only use released versions! And BTW: you can track which snapshots were used for old builds by checking Jenkins' fingerprints.

          Mike Power added a comment -

          As much as rebuilding old builds would be nice. What I am really interested in is slowing down the rate at which I get bad SNAPSHOTS. Bad SNAPSHOTs break my builds, cause my developers to waste time identifying it was not their change, prevents them from doing additional work, and additional bad stuff. The given example with a loooot of jars to archive also has a lot of continuous integration going with those SNAPSHOTS. Without any quality controls in place it also has a loooot of continuous breakage. I want to find some imaginary happy place dubbed continuous quality where I have all the benefits of continuous integration without all the detriments of continuous breakage.

          What I would like to be able to do is run a bunch of tests against a SNAPSHOT (and its transitive SNAPSHOT dependencies) first before I hand it over to developers or continuous integration builds.

          The idea would be to combine this feature with the jenkins maven repository plugin. That plugin as you maybe aware allows you to use another build as a maven repository. With that in place I could make one build pull down new SNAPSHOTS integrate it with my code and then run all my tests against the result, call it an acceptance build. I might keep a few of these builds around but not many. Then my developers, and my CI builds would use the last successful acceptance build as the maven repository they go to for SNAPSHOTs.

          This puts one build of latency between me and my SNAPSHOTs dependencys for continuous integration. Not a bad price to pay for eliminating most of my breakages through dependencies.

          Mike Power added a comment - As much as rebuilding old builds would be nice. What I am really interested in is slowing down the rate at which I get bad SNAPSHOTS. Bad SNAPSHOTs break my builds, cause my developers to waste time identifying it was not their change, prevents them from doing additional work, and additional bad stuff. The given example with a loooot of jars to archive also has a lot of continuous integration going with those SNAPSHOTS. Without any quality controls in place it also has a loooot of continuous breakage. I want to find some imaginary happy place dubbed continuous quality where I have all the benefits of continuous integration without all the detriments of continuous breakage. What I would like to be able to do is run a bunch of tests against a SNAPSHOT (and its transitive SNAPSHOT dependencies) first before I hand it over to developers or continuous integration builds. The idea would be to combine this feature with the jenkins maven repository plugin. That plugin as you maybe aware allows you to use another build as a maven repository. With that in place I could make one build pull down new SNAPSHOTS integrate it with my code and then run all my tests against the result, call it an acceptance build. I might keep a few of these builds around but not many. Then my developers, and my CI builds would use the last successful acceptance build as the maven repository they go to for SNAPSHOTs. This puts one build of latency between me and my SNAPSHOTs dependencys for continuous integration. Not a bad price to pay for eliminating most of my breakages through dependencies.

          kutzi added a comment -

          Thanks for the clarification.

          I'm not completely familiar with what the maven repository plugin can provide, but to me it sounds like what you want is already 99% provided by it.
          See https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Maven+Repository+Server 'Chained Builds'
          Isn't that what you're looking for?

          kutzi added a comment - Thanks for the clarification. I'm not completely familiar with what the maven repository plugin can provide, but to me it sounds like what you want is already 99% provided by it. See https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Maven+Repository+Server 'Chained Builds' Isn't that what you're looking for?

          Mike Power added a comment -

          You are right about everything. It is the 1% that is preventing me. The part that is missing is that Chained Builds will only give dependencies actually built on Jenkins. If the build depends on one or more SNAPSHOTs actually built some where other then the Jenkins machine Chained builds will not provide a repository for them. If you think about it, the Chained builds maven repository is operating much like a nexus repository that is proxying multiple other repositories. Those repositories it is proxying are the individual job repositories for each SNAPSHOT. The only artifacts those jobs archive are the artifacts produced by the job. Thus the Chained Builds repository is the sum of all transitive dependencies built by that Jenkins and no more.

          This is similar to the maven dependency problem. Maven works awesome 99% of the time resolving the dependencies for a project. It is the 1% of the time where the dependency needed is not actually a part of the maven repository. In this case there are at least two solutions available.
          1) Manually install the dependency in the maven repository
          2) Use a system dependency to the file on the disk.
          Neither of which is as elegant as the original solution. But they do provide a stop gap solution until the owner of the dependency can establish the process to upload their artifacts to maven.

          Similarly I am looking for a solution albeit less elegant that will pull in the rest of the dependencies that I am not building on my jenkins at this time.

          Mike Power added a comment - You are right about everything. It is the 1% that is preventing me. The part that is missing is that Chained Builds will only give dependencies actually built on Jenkins. If the build depends on one or more SNAPSHOTs actually built some where other then the Jenkins machine Chained builds will not provide a repository for them. If you think about it, the Chained builds maven repository is operating much like a nexus repository that is proxying multiple other repositories. Those repositories it is proxying are the individual job repositories for each SNAPSHOT. The only artifacts those jobs archive are the artifacts produced by the job. Thus the Chained Builds repository is the sum of all transitive dependencies built by that Jenkins and no more. This is similar to the maven dependency problem. Maven works awesome 99% of the time resolving the dependencies for a project. It is the 1% of the time where the dependency needed is not actually a part of the maven repository. In this case there are at least two solutions available. 1) Manually install the dependency in the maven repository 2) Use a system dependency to the file on the disk. Neither of which is as elegant as the original solution. But they do provide a stop gap solution until the owner of the dependency can establish the process to upload their artifacts to maven. Similarly I am looking for a solution albeit less elegant that will pull in the rest of the dependencies that I am not building on my jenkins at this time.

          kutzi added a comment -

          IMO this sounds like it best fits as an extension to the Maven repository server plugin

          kutzi added a comment - IMO this sounds like it best fits as an extension to the Maven repository server plugin

          Mike Power added a comment -

          Either way it requires me to understand how the maven plugin itself work, don't go holding your breath over this.

          Mike Power added a comment - Either way it requires me to understand how the maven plugin itself work, don't go holding your breath over this.

            Unassigned Unassigned
            mpower_dodtsair Mike Power
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: