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 On Wed, Oct 29, 2014 at 3:18 AM, Fay Wong <philip584...@gmail.com> wrote: > Many thanks to Barrie. > > I think what you have clarified is the normal flow of maven practice. > > The "deploy" in the context of my previous post means: our developer invoke > a "mvn deploy" command to share the output(bytecode) through the repository > so as to shorten the build time of whole project(as its code base is too > large). Our goal is modular compiling and packaging. > > Currently my pain is our developer would deploy broken bytecode to our dev > repository and broken others work. Could i define a intermediate > repository, everytime they deploy, jenkins will verify it. if pass, then > depoy it into dev repository, otherwise, revert the intermediate repository > to keep sync with dev repository. > > Is there a easier way to achieve this? > > 2014-10-29 13:07 GMT+08:00 Barrie Treloar <baerr...@gmail.com>: > > > On 29 October 2014 14:00, Fay Wong <philip584...@gmail.com> wrote: > > > > > Hi all, > > > > > > Is there any solution to pre-verify the deploy before it actually got > > into > > > the repository? > > > > > > Take this usecase for example: > > > > > > In a team of 40 developer, every developer will deploy their module at > > any > > > time, once there's a error, > > > > > > the final output software won't work and blocks other developer's flow. > > > > > > So is there any pre-verify solution(such as jenkins CI-server) to be > > > enforced before the deploy overlapped the previous deploy? > > > > > > Not really, this is a process issue. > > > > You need to decide what is in a state of flux, and then when people > should > > consume it. > > > > I'm assuming by "deploy" you mean a released artifact and not a snapshot > > one. > > Generally, you should not be deploying your snapshots for consumption by > > other developers, as snapshots could break at any time and you impact > > anyone who depends upon them. > > Instead, when a developer needs a snapshot version they check out the > code > > and building it themselves, then when they need to import new changes > they > > pull in the changes to the code and rebuild. That way the developer gets > to > > choose when they will consume potentially breaking changes. > > > > If these are released artifacts then you have lots of choices on how to > do > > this. > > *) By using your version control system and some form of isolation (e.g. > > branches). > > When the new version is released the developer still needs to pull > those > > changes in, and if there are breaking changes can revert back to the > > previous version. > > *) Have someone in a QA role validate that the artifact works prior to > > promoting that version in you parent pom. > > > > The act of deploying into your Maven Repository is independent from the > > consumption of that artifact, it shouldn't be breaking peoples build > until > > they start using it. > > >
