Le samedi 10 février 2018, 00:10:14 CET Olivier Lamy a écrit : > Policy: snaphots from master branches (and possibly long lived maintenance > branches) are deployed automatically. +1 for long lived branches, the version must have some differentiator from master
> > Build setup: downstream projects must be build after a master build and > deploy. if possible, that would be great Regards, Hervé > > On 9 February 2018 at 13:03, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
