Do not consume eclipse-theia without any quality gate

[rhopp]

Is your task related to a problem? Please describe.

Currently, che-theia:next (build from che-theia master branch) is being build nightly with lastest bits from https://github.com/eclipse-theia/theia without any checking, that changes in upstream eclipse-theia are working with other Che components.
This approach is not good, as it often breaks development (nightly) version of Che.
This approach also causes our builds to be non-reproducible. che-theia built on one day, could be completely different than che-theia built day later, even though there were 0 changes in the codebase.

Describe the solution you'd like

We should figure out some mechanism in che-theia master branch of tracking commits from upstream eclipse-theia which are used for building che-theia.
This way we could periodically send PR to che-theia to update upstream dependency (commit hash?).
This would allow us have build reproducibility and we can also leverage the PR check job (quality gate) in this process.

Describe alternatives you've considered

Another possibility is to intoduce this quality gate in th nightly build just before pushing che-theia images into docker registry. This would allow us prevent breaking Che as it is, but it's more reacive approach, than directly tracking the upstream dependency in code. And this approach doesn't solve the build reproducibility issue.

[benoitf]

Sorry but a broken image should NEVER be pushed if it's breaking
Breaking Che Theia is a separate issue.

In alternative, it should check directly the PR of Theia as well to eagerly track potential future failures.

I think also this topic has already been discussed but I never saw happy paths / more tests on upstream as well as it was decided

[tsmaeder]

This approach also causes our builds to be non-reproducible

The fact that we're building against master every night does not cause the builds to be non-repeatable: we could easily record the commit hash or even tag the built state, even if the hash changes every night.
Also, I don't think nightlies need to be repeatable.

[tsmaeder]

I think we should build against theia master every night: I want to know as soon as possible if our code does not work with theia master.

[tsmaeder]

We could treat updating to the latest theia master like a PR: i.e. it would have to pass the quality gates.

[vparfonov]

We need to start nightly builds procedure. If we have failed test during nightly test NO PUSH any image and rising problem via emails/chats. In this case we will detect problem ASAP.

[l0rd]

I think we should split this issue in 2 tasks:

1. setup a Che PR check upstream (on Theia): that won't be a blocker to merge the PR but we will know that something breaks Che even before the PRs are merged in Theia. @benoitf should work on it.

2. Stop publishing nightly che-theia images if the PR check (or any other test) do not pass. @evidolob @rhopp can on of your team take care of this second task?

[benoitf]

FYI I asked on Tuesday call of Theia dev meeting about reporting status check of che-theia in upstream theia and ppl are ok to try
https://github.com/eclipse-theia/theia/wiki/Dev-Meetings#minutes-2019-11-26

[rhopp]

Preferred solution will be implemented in #15291

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.