On 4 October 2013 08:42, teilo <[email protected]> wrote:
>
>
> On Thursday, 3 October 2013 20:37:27 UTC+1, Stephen Connolly wrote:
>>
>>
>>
>> On Thursday, 3 October 2013, teilo wrote:
>>
>>> Hi Stephen,
>>>
>>> Is the literate plugin going to be the only route into the multi-branch
>>> job?
>>>
>>>
>> I am sure somebody may use the branch api to implement other types... I
>> have a freestyle multi branch but there is just too many build differences
>> for it to be useful and a ton of UI glitches because plugins assume they
>> are owned by <? extends Job>
>>
>>
>>
>>> Reason being for enterprisy software we need to enforce things in a
>>> build/release so I can't let my users run abitrary maven invocations that
>>> change the build (and make it unreproduceable).
>>>
>>> e.g. they should not be able to change the settings by using mvn -s
>>> $workspace/some_setting_with_**external_repo.xml -DskipTests=true
>>>
>>
>> But they can just change the pom to skip tests anyway... You have a false
>> sense of security...
>>
>
> That was a bit of a bad example - but actually if they want to skip tests
> in the POM then that is 100% ok - as we know that the tests were not run on
> a specific build.
>
>
>>
>> And if they want to use a different settings... Invoker and an
>> alternative pom file.
>>
>>
> 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...
>
> 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?
The SCM revision will still be buildable if Jenkins built it once before.
Or is it that you are worries about people injecting alternative
settings.xml in the build command?
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
>
> 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...
>
>
>
>>
>>
>>>
>>> but at the same time its nice that you just branch and get a job (from
>>> say a job that's created from some kind of template, and that should allow
>>> the user to specify the properties exposed by that template only...)
>>>
>>> (you haven't yet beaten my addiction to the maven job type...)
>>>
>>
>> I'm not done... There are more tricks up my sleeve
>>
>
>
>
> --
> 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.
