Need to create branch that would track upstream 6.14 SNAPSHOT version and fix incompatibilities in a timely manner

[ibuziuk]

Need to set up a branch that tracks upstream SNAPSHOT, and fixing build issues during the sprint as they come up so that the rollout to 6.14 at the end of this sprint is easier
We had similar branch / PR for 6.13.0 - #965

[rhopp]

How that goes along with the job checking upstream compatibility? If we had such branch every time, that job would not make much sense, because PR check job on the tracking branch (PR) would do the same work.
Only difference would be, that PR check job would be triggered only on push to branch/commenting that PR and the check job would be triggered nightly. On the other hand, upstream check job would always try to rebase our master to upstream master, but on the tracking branch we could fix issues as they go.

Most ideal solution would be running the check job nightly with the tracking branch... But right now I don't know how to achieve that.

[ibuziuk]

@rhopp I believe the best strategy would be using mixed approach with CI / and branch. We should have:

• job that checks build compatibility with latest upstream [1] (Already exists)
• job that runs integration rh-che integration tests against latest upstream [2] (In QA Sprint backlog)
• if one of those jobs is failing we would start investigation and create branch / PR for making rh-che compatible with upstream and provide relevant fixes that would be automatically tested by PR check job

If we had such branch every time, that job would not make much sense, because PR check job on the tracking branch (PR) would do the same work.

The job does makes sense since it is great automated indicator that rh-che becomes incompatible with upstream. Until jobs are green we would not need to create any branches and do any manual work

[1] https://ci.codenvycorp.com/view/All/job/rh-che-ci-master/
[2] https://github.com/redhat-developer/che-functional-tests/issues/368

[amisevsk]

PR here: #1020

[amisevsk]

We need a branch because there are changes we need to make (e.g. for the 6.13 snapshot PR) that are necessary for snapshot builds but will break current version builds (e.g. SNAPSHOT changes an interface). This means that there can be commits that are necessary in rhche that have to be merged alongside the change to the next version.

[garagatyi]

In this issue I described how we can achieve everything needed with just 1 job that would maintain just 1 branch. It would be a more complicated job with some scripting but it would show us the real picture in one place.
With such a job that creates PR for the new upstream version, we would be able to do PRs for fixes in the case of an incompatibility and merge it in that branch. For me, it looks like an ideal solution for the time being.
And we would be able to remove the job from upstream which would not make sense.

@rhopp @ScrewTSW @Katka92 @ibuziuk @davidfestal @amisevsk WDYT?

[rhopp]

@garagatyi Yeah... At first I thought it would be unnecessarily complicated, but yeah.... I think it's better approach.

[Katka92]

I've created an issue about that: https://github.com/redhat-developer/che-functional-tests/issues/388

[garagatyi]

Just got an email about yet another CI failure with 6.14 https://ci.codenvycorp.com/job/rh-che-ci-master/740/console