On 4 October 2013 09:39, teilo <[email protected]> wrote: > > 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!) >
Oh way cool.... you've just given me an idea for another enterprise plugin: multi-branch-templates plugin That should be easy... and because it's templates we don't have the UI glitches we see with my (currently closed source) free-style multi-branch plugin https://rm.cloudbees.com/issues/2111 That should make you happy... now just to convince Harpreet to put it on the backlog... feel free to file a ZD ;-) > > > > >> >> >>> >>> 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
