Long rebase using gerrit

Question

Our project is multi-module maven project. This project is dependent on another multi-module maven project. The relationship of poms (both aggregation and inheritance wise) is like

parent-super-pom
|---parent-module-1
|---parent-module-2
|---parent-module-3
|---...
|---parent-module-n
|---child-super-pom
    |---child-module-1
    |---child-module-2
    |---child-module-3
    |---child-module-4

Everything in parent project is managed by a separate team, lets call it framework. Everything in child project is managed by our team, lets call it product.

Now framework is upgraded to use spring-boot along with many other breaking changes. We need to start development to upgrade product to use framework's latest tech. This upgrade process would take around a month (with lots of un-compile-able commits) as there are a lot of changes which need to be taken care of to make the application work. In the mean time, product would also be developing features on its own on the old maven environment. What would be the best way of approaching this situation?

We use gerrit code review. The changes are first pushed on gerrit, there are automatic jenkins job triggers to run basic tests. The change can be submitted only if the build(s) pass. There are also builds which can be demanded based on some triggers through gerrit comments like to run time consuming web-tests, integration tests, etc.

My idea

By force-push in the following context I mean that it has to bypass gerrit i.e. pushed directly to the branch and not the actual force-push that recreates git history

• Create a feature branch in product for upgrade, say feature/upgrade
• Make sure temporary CI jobs are setup for this branch w.r.t. new environment including the on-demand ones
• Push changes to this branch required for upgrade until the application can be run normally
• Rebase the branch on master from time to time to avoid bulk conflicts at the end of upgrade (would require force-push on feature/upgrade)
• At the end, push all the changes from feature/upgrade to master (would require force push on master) and now configure CI jobs on master to start using config similar to that in newly created temporary jobs

The flaw with this idea is force-push. We ensure that the branches are locked against such push as it makes the branch vulnerable to mistakes and only few people in organisation can make such submissions. May be I am unaware of some gerrit feature which I could leverage here or my idea is completely wrong. I need to know what is the best approach to deal with such situation.

Answer 1

Why don't you setup small process that monitors gerrit events and if commit is pushed into refs/for/$your_feature_branch then it automatically set Verified flag to +1. You can even wait for Jenkins to set Verified to whatever value on that branch and then based on that event set Verified to +1 again. This way you are guaranteed to be able to merge you commits independently of builds succeeding of failing in Jenkins.