On 30 October 2014 08:38, Curtis Rueden <ctrue...@wisc.edu> wrote: > Hi Fay, > > > Could i define a intermediate repository, everytime they deploy, > > jenkins will verify it. > > Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins > has deploy permission to your remote repository. So your devs can no longer > run "mvn deploy" from the CLI and expect it to work, but instead just push > to master (or whatever integration branch) and then Jenkins runs the build. > > Once Jenkins does your deploys, you can set up your jobs to test for more > stringent conditions before actually doing the deploy. E.g.: > > $ git clean -fdx > $ mvn clean install > $ bin/verify-artifacts.sh > $ mvn deploy > > And "verify-artifacts.sh" does whatever further programmatic testing you > need. > > OTOH, in many cases, you don't need a shell script -- often times, you can > get what you need using Maven plugins like Surefire, Failsafe, and > Enforcer. If you go that route, it might be enough so that devs running > "mvn deploy" won't deploy bad stuff to the repo by default (unless they are > aggressive enough to run e.g. "mvn -DskipTests deploy" which would be > pretty bold). > > Regards, > Curtis
Whether its Jenkins, or a developer, you've still pushed a release that could break the build. This is where you need some isolation available to your workflow. Stuff breaks - it happens, Fay needs to determine how they want to deal with it.
