Write down the policy you would like

On 9 February 2018 at 12:25, Olivier Lamy <ol...@apache.org> wrote:

> On 9 February 2018 at 12:01, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
> > Document what you think the policy should be and we'll go from there.
> >
> > My (current) preferred policy is:
> >
> >     There is no automatic deployment of snapshots. Developers can
> manually
> > publish snapshots on an as needed basis and if they require downstream
> > builds to pick those up then they need to configure the downstream jobs
> > with the explicit timestamped snapshot version.
>
>
> > The above, IMHO, leads to the least amount of confusion as to why
> specific
> > builds are failing, but it does not provide as nice a user experience as
> I
> > would like.
> >
> > Ideally I would like each branch name to be able to pull the latest
> > snapshots from matching branch names of other repositories in the org
> > folder where the artifacts were captured by Jenkins in the "verify" phase
> > or by using a different "deploy" plugin. That would enable the CI server
> to
> > manage the lifetime of those artifacts and trigger cross-repository
> > dependencies. The end developers would not see these CI only artifacts,
> and
> > would have to build and install locally. This has the advantage that your
> > local build always uses what you locally installed... you don't have to
> > worry about starting the next day and doing `mvn clean install` on the
> repo
> > you were trying to debug... going to make a cup of coffee... and coming
> > back to find stuff not working because you didn't see Maven doing it's
> "oh
> > I haven't checked for newer snapshots in 24h, I last checked yesterday
> > morning... oh look a new snapshot, let's ignore the snapshot that was
> > installed locally at 4pm yesterday" and replacing your locally installed
> > snapshot with the latest from the CI server.
> >
> Sorry but I don't want to go to over complicated things and too much
> bureaucracy.....
> IMHO The problem was more due a monolithic build of all shared/plugins
> etc... (as if only one part of the source was modified everything was
> rebuild and redeploy even non touched modules)
> We had a very convenient auto deployment in the past of trunk(s)/master(s)
> Someone modified a shared library so it's deploy then a build of downstream
> projects are scheduled to verify everything is still working,
> And then everything is deployed for early testers.
> so it's pretty simple (and IMHO should be stay very simple as we are a very
> limited number of volunteers who don't want to waste in over complicated
> procedures...)
>
> >
> > But anyway, that is my opinion and rationale. We are a community, my
> > opinion should not dictate what the community wants to do.
> >
> > I do feel that we need to write down and document what our policy
> actually
> > is before we try and implement it.
> >
> >
> >
> > On 9 February 2018 at 09:06, Olivier Lamy <ol...@apache.org> wrote:
> >
> > > Perso I don't want anything else than master deployed..
> > > wip feature branch doesn't make really sense to be deployed.
> > > and makes our life easier :-)
> > >
> > > On 9 February 2018 at 07:40, Stephen Connolly <
> > > stephen.alan.conno...@gmail.com> wrote:
> > >
> > > > I personally think there are a lot of issues with CI automatically
> > > > deploying snapshots...
> > > >
> > > > Some of these issues a social, and some are not.
> > > >
> > > > Hervé, Olivier,
> > > >
> > > > I suggest we start by writing down the policy you think you want...
> > i’ll
> > > > poke holes, you fix or ack until we get a good compromise... then we
> > can
> > > > implement.
> > > >
> > > > Policy should cover:
> > > > * what to do on different branches
> > > > * who is responsible for snapshots and non snapshots
> > > >
> > > > Eg
> > > >
> > > > CI will auto deploy snapshots only on the master branch. Other
> branches
> > > > manually with the version changed to include branch name as a
> > qualifier.
> > > > Releases will be deployed manually, ideally from the master branch
> > only.
> > > > --
> > > > Sent from my phone
> > > >
> > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Reply via email to