Policy: snaphots from master branches (and possibly long lived maintenance branches) are deployed automatically.
Build setup: downstream projects must be build after a master build and deploy. 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 > > > -- Olivier Lamy http://twitter.com/olamy | http://linkedin.com/in/olamy
