> But you are assuming my maven enforcer rules etc. are the only line of >> defence here. The MRM can also play an important part :-) >> > > Yes which is why I have another trick up my sleeve as part of my "make > maven better on jenkins and get rid of the ugly aberration that is the > Maven project type" plan... >
I guess that is the trick I have been waiting for for a while... You've made a lot out of this - I'm expecting the moon on a stick solution :-) > > >> >> Besides that can you configure things that are not reporters? >> e.g. wipe out workspace, >> > > That is something that does not make sense in SCM, so that is configured > from Jenkins > > >> always checkout a fresh copy, >> > > As for wipe out workspace > > >> enable a release plugin... >> > > That is awaiting the "tasks" support that KK has said he will help > write... basically the way this will work is you will enable a branch > property that defines the promotion tasks to support for that branch... you > will specify the heading keyword to identify the steps for that task and > the environment to run the task on... so to enable releasing from Maven you > would do something like > > # To make a release > > mvn release:prepare release:perform -B > > and then in jenkins you just tell jenkins that, e.g. the master branch has > a release task with the keyword "release" in the heading > > Thus you will only be able to cut releases from the master branch. > > >> >> >> >>> Plus you can just watch what shit they are committing... You need to do >>> that with the poms anyway >>> >> >> No I can't (and actually I don't). If I could do that then we wouldn't >> need the Template plugin as I could watch all Jenkins job creation :-) >> >> You are correct in that there is a little bit of an arms race going on - >> but most of this is not actively trying to create non-repeatable builds - >> it's just people not always thinking things through and the system can >> probably automatically pick up 95+% of that. >> > > What is a non-repeatable build in this context? > I should have also included traceable so replace with "non-repeatable non-traceable" it is a build that we can't trace back to the source code, or for which if we checked it out onto a clean machine setup with the correct OS/java/maven could not run "mvn install" and have identical binaries in the future (we record the JDK version and maven version used to build as well as the build host which will tell us the OS). Obviously there could be cases where some bad unit tests have some dates in them and these could fail if time has moved on - but they should be easily identifiable) > The SCM revision will still be buildable if Jenkins built it once before. > > Not true. If you change the settings, or disable enforcer rules etc you can add a external repository. As we all know some of these external maven repositories have a habit of being here one day and gone the next. That is why we force everything via our MRM which will keep every single release it downloads forever to handle just this case. There are also times when the upstream repo replaces a release version (even sonatype has let this happen on their hosted repositories in the past!) So just because you built something today doesn't mean that the dependencies/plugins you need to build it tomorrow will still be around and at the same place. There are also occasions where someone sets a "release version" on trunk and would let jenkins "mvn deploy" - this could be ok as far as the MRM is concerned yet there is no tag in SCM. As there is no tag there it may be on a branch that is a personal branch or a throwaway branch that can be deleted (e.g. you allow deleteion of personal/** but not releases/** - but don;t allow deletion/redefinition of tags) Or is it that you are worries about people injecting alternative > settings.xml in the build command? > That would be one of my big concerns with this. (Sonar being another root of all evil..) this setup would also allow users to have jars in SCM that they mvn install:installFile... (with maven2 you could have done this with system scope - but the enforcer rules should have prevented this). The above isn't about reproduceability - but to make sure that people don;t check in jars to SCM - and that they go via the 3rd party reposiroty and have their licence/useage tracked. All our main source build jobs use the same template that allows you to specify the following, 1) source location 2) users to email 3) java version 4a) maven version 4b) number of threads (-T...) 5) If you want any findbugs violations to mark the build as unstable 6) if you want any checkstyle violations to mark the build as unstable 7) slave restriction With just that you have a whole host of plugins configured - and just managed. You get reports even if you choose to ignore them so the commands to run are (for a ommit build) always the same mvn install checkstyle:checkstyle findbugs:findbugs, and it prevents you from doing a lot of stuff like adding pre-build commands etc that users could use to work around various things that could be construded as slowing down development but are all in for good reasons. > We are nowhere near "it works on my machine" land, though I suspect you > will need to see my maven improvement plans before you fully believe me > Yup - I need to see it. I think the idea is great and can see this being fantastic for open source, or where you have a smaller company/team where you can check every commit to the build settings, I'm just not sure I could use it in an enterprise without being bitten by its ultimate flexibility (which is one reason why we use templates - but that gets us a plethora of jobs for the dozens of branches in each project!) > > >> >> There are several thousand projects+branches - it would take a full time >> person to watch all of that - you could say that this could be somewhat >> automated - but even that has human overhead to setup these jobs when new >> projects are added, maintain mapping of project/branch to user+manager >> mapping etc... >> >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
