Write down the policy you would like On 9 February 2018 at 12:25, Olivier Lamy <[email protected]> wrote:
> On 9 February 2018 at 12:01, Stephen Connolly < > [email protected]> 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 <[email protected]> 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 < > > > [email protected]> 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 >
