If implementing a solution like the one proposed by Adam works, then why
not do it? It gives everyone choice, without the need to create yet another
plugin that is basically an "on/off"-switch.

In our case, our developer teams orders a Jenkins that, at first boot, gets
prepopulated with the requested Github Organizations, that the developer
team wants. This is fully automatic with some groovy-init-scripts in a
dockerized Jenkins instance.

Our Jenkins instances contain no state, since everything is configured by a
combination of JCasC and Jenkinsfiles. To keep the Jenkins instances from
growing stale, we treat them as cattle, and as such these instances have a
relative short lifetime.

Whenever a developer wants to create a new instance, they must wait for all
the builds, of all the branches in all the repositories in all their
organizations to end, before actually moving forward, they have web-hook in
their Github Organizations that trigger new builds on commit. This creates
a lot of builds, that IMO are a waste of time, since all the code in those
repositories probably already has been built. Having a flag that does what
has been proposed, solves this issue for us.

We do have a build strategy, albeit a simple one. Deployable artifacts are
built from master-branch. Whatever processes, rules, and occult rites each
developer team has to perform getting their code to master, is beyond our
concern.

We do not believe in requiring developer teams to name their branches in a
certain way. It is the responsibility of the developer team to have a
naming strategy for their organizations, repositories, and branches. We
treat our developers to be professionals and thus expect them to be just
that, professional. Being a professional implicitly means that you are a
responsible employee, and thus do not need to be micromanaged.

-- 
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].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAKob%2BgPuA_i9GMg9kP20xvgC-TpcWRPM6O8sxagEZPPTFYi%2Bdg%40mail.gmail.com.

Reply via email to