On 25 September 2014 15:13, James Nord (jnord) <[email protected]> wrote:
> > > What's the killer feature is > > > 1) automatic (zero conf) finding of artifacts / test reports / > > > findbugs report pickup etc etc... > > > > > > > Well James, you do know *you* could use templates (as you have the > > enterprise plugins ;-) ) and give a locked down build. > > With literate? How - I did raise a call about that (feel free to take > this off list :-) ) > > I already use templates for the maven2/3 project type to lock it down! > I was more saying you could use templates to lock down a freestyle and that way avoid the evil one! > > > > And also being able to lock down what the CI system will run to > deploy... > > > That is if some devs have control of their own builds when an enforcer > > > rule fails (your build is not repeatable) they will look up enforcer > > > and add -Denforcer.skip > > > > > > > So you are missing the full context. The literate-api allows for > different > > providers. There are actually two providers in literate-api at present: > the > > README.md driven one and a .travis.yml driven one (with a very incomplete > > parser... but I always like to test plugable APIs with more than one > > implementation to make sure the design is right) > > > > The way I see literate having advanced Maven support is via two modes: > > > > 1. Wherein you specify the literate commands as being for a "maven > shell"... > > something like > > > > > # Build > > > > > > We build with Maven using the following phases > > > > > > ```mvnsh > > > clean verify > > > ``` > > > > When I add asciidoc support, that has a much nicer way to specify the > syntax > > > > 2. Wherein you just tell it to use the pom.xml directly (i.e. a > literate-api pom > > based parser that is activated by just having a pom.xml in the root > (plus a > > marker file to say this is a buildable branch) > > > > Then in the config for the literate job you would specify the goals you > want > > executed for that parser > > So that's more what I'm after - but I also want Jenkins to be intelligent > about picking up reports/artifacts (clover is a PITA and if you do > target/*.jar **/target/*.rpm it will pick up clovers instrumented jars / > rpm...) - even though they are never installed into the local repo. (the > Maven2/3 type job is clever in this regard and won't pickup those > artifacts). > Nahh my idea is to have an execution listener and get that to report artifacts back to jenkins > And I also want to be able to make releases with Jenkins for this branch > :-) (did I say moon on a stick?) > Literate already has lightweight promotions for that... a pom based parser would just report the release goals as a "promotion" > > > > Yes they could add <phase>none</phase> to the enforcer config - but > > > the ones that are intelligent enough to do that know better and fix > > > the issue rather than hide it! > > > Neither of the above are possible with the literate job type. > > > > > > > Not yet... but once I get the time to write some code... > > Until that time you'll get people continue to use the job that you > consider evil :( > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
