Introduce Blueprint Update Channels

[tsmaeder]

Feature Description:

There is an ongoing effort to enable using Theia Blueprint as the IDE for developing Theia itself. Currently, we only publish a Blueprint version for ever major release (if I understand correctly). My proposal is to introduce different "update channels" for Theia which are updated at different frequencies. There should be three channels:

1. Release (published after every release)
2. Weekly (once a week)
3. Nightly (once a day)

I'm not sure it makes sense to publish on ever commit to Theia, t.b.h.

IMO, #235 is probably a prerequisite for this feature to be used sensibly.

[JonasHelming]

I get "release" and "nightly", but what is the thought behind weekly?

[tsmaeder]

The idea is that when someone screws up the build, you have time to notice before everyone using the channel gets their dev-environment gets broken. You can have some folks on the nightly channel that notice and tell the other's to pause updates, until the problem is fixed. Since it's just a "promoted" nightly build, it costs nothing, but can save bandwidth on the update servers.

[JonasHelming]

@jfaltermeier and me discussed this also with regards to #235
There are some issues, most importantly: Portable installations do not support updates.
However, wouldn't it be sufficient, if a portable version would be build every day? This way, you can very easily install a new version by just downloading the new portable?
@tsmaeder ?

[tsmaeder]

I don't really understand how a limitation of portable installations restricts what we can do with regular installs. Aren't these two separate concerns? And I don't think creating a portable install is an equivalent solution: first, it's a nuisance and folks will quickly stop installing the newest every morning. Second, different installs should have different sets of configurations and installed extensions. An older build might not be able to run the newest built-ins, for example.
If VS Code can do channels, why can't we?

[jfaltermeier]

As far as I could see VSCode also does not allow to have multiple installations on Windows. When I run the user installer on windows again, it will reinstall VSCode over my existing installation.
The VSCode nightly/insider build is basically a different application that updates more often. Since it is a different application we can install it next to an existing VSCode.

We could do the same for Blueprint, so having a regular Blueprint application and a Blueprint Nightly application.

However this then does not really fulfill #235, because we are just working around it by using different application names for both channels. However this may be enough?
Otherwise we require the portable installations again, which do not offer updates.

[tsmaeder]

For the dog-fooding use case, it really does not matter whether it's the same application or multiple applications. In fact, having completely separate areas for installed plugins, settings, etc. might be a good thing. The installer could let you choose which "channel" to install.

[jfaltermeier]

I will have a look at this in more detail now.
Btw, at the moment there does not seem to be a nightly/next Theia Build any more: eclipse-theia/theia#12699
Next version is still pointing to 1.39.0 https://www.npmjs.com/package/@theia/core?activeTab=versions
So this is something that we might have to bring back as well

[tsmaeder]

So this is something that we might have to bring back as well

We could build from source, no?

[jfaltermeier]

So this is something that we might have to bring back as well

We could build from source, no?

Probably yes, but can you elaborate why this would be preferable?

Since we would have to duplicate Theia's github build workflows to some extent, which itself is not nice, there is also room for error when it comes to the Theia build. Every issue we see could be caused by some mis configuration in the workflow. And we have to maintain the additional workflows in the long run.
When the packages are not published, it makes it shakier to reproduce issues. When we know which next version was used, we can simply consume it again on a different machine and test. Otherwise we have to checkout theia, find the git commit, and build from source, which might lead to different results.

I find it weird that consumers of Theia would have to build their own integration points and have no official previews at all to test against.

[tsmaeder]

Probably yes, but can you elaborate why this would be preferable?

We would not have to publish "next" releases, which were discontinued for good reasons. In addition, we would have a template for building applications against theia source, which seems to pose problems for folks, right now.

Since we would have to duplicate Theia's github build workflows to some extent, which itself is not nice, there is also room for error when it comes to the Theia build. Every issue we see could be caused by some mis configuration in the workflow. And we have to maintain the additional workflows in the long run.

We would not have to duplicate anything: if we have a build script that can build a blueprint package from source, we can just call this script in the github build. But we can also invoke it in inner loop development, for example trying out changes to the build more quickly than to having to push it to github and let the CI machinery run.

When the packages are not published, it makes it shakier to reproduce issues. When we know which next version was used, we can simply consume it again on a different machine and test.

I don't agree with this: we can record the git commit we have built from in the package. We need to know that info anyway if we want to know which version of the source has any given bug.

[jfaltermeier]

Probably yes, but can you elaborate why this would be preferable?

We would not have to publish "next" releases, which were discontinued for good reasons.

As far as I saw on the ticklet the reason was that we can't clean up next version on the official npm registry.
But imo this is not an argument against next versions, but against publishing the next versions to this registry. We could look at different registries, e.g. Github.

Also having a single official next build will reduce overall resource consumption, when compared to a scenario where every interested adopter has to build Theia themselves on a nightly basis.

In addition, we would have a template for building applications against theia source, which seems to pose problems for folks, right now.

Since we would have to duplicate Theia's github build workflows to some extent, which itself is not nice, there is also room for error when it comes to the Theia build. Every issue we see could be caused by some mis configuration in the workflow. And we have to maintain the additional workflows in the long run.

We would not have to duplicate anything: if we have a build script that can build a blueprint package from source, we can just call this script in the github build. But we can also invoke it in inner loop development, for example trying out changes to the build more quickly than to having to push it to github and let the CI machinery run.

I was talking about the github build workflow descriptions. As far as I know those have to be checked in at .github/workflows. Those have to be kept in sync with the main repository, e.g. when it comes to node or python versions. (https://github.com/eclipse-theia/theia/blob/master/.github/workflows/ci-cd.yml)

When the packages are not published, it makes it shakier to reproduce issues. When we know which next version was used, we can simply consume it again on a different machine and test.

I don't agree with this: we can record the git commit we have built from in the package. We need to know that info anyway if we want to know which version of the source has any given bug.

Yes we need this info when the bug is in Theia, but the bugs could be caused by the adopter's code as well. Rather than being able to just debug an issue, they have to build Theia first.

[tsmaeder]

Also having a single official next build will reduce overall resource consumption, when compared to a scenario where every interested adopter has to build Theia themselves on a nightly basis.

I'm not really worried about overall resource consumption: many adopters, much resources! That said, building applications against a "nightly" version of published packages is a just a workaround for not being able to build against any given commit in the repo. If we can build a theia application against any commit, we trivally can build nightlies, but not the other way round: it's just the more powerful concept. Are you worried it's going to be difficult to implement?

I was talking about the github build workflow descriptions. As far as I know those have to be checked in at .github/workflows.

My philosophy is that CI build scripts should be minimal: you should be able to do the same locally with scripts independent of the CI system, basically: the CI job is responsible for building the correct environment and then invoking the build script. I've had to learn the hard way that you cannot debug CI scripts in a meaningful way, so anything we can keep out of there is a boon.

Yes we need this info when the bug is in Theia, but the bugs could be caused by the adopter's code as well. Rather than being able to just debug an issue, they have to build Theia first.

Building Theia is something you do once, if you don't make changes, and it takes (over time) sth like a minute max.

We're discussing pros/cons here, but I get the feeling we differ on whether it is desirable to build a blueprint package locally against a checked out source tree of Theia. I think that's super useful. What's your view?

[jfaltermeier]

I agree that it should be easy for adopters to build Theia locally and integrate it with their own code. But the main use case for this are situations where you want to fix a bug or contribute a new feature in Theia in my opinion. At least I only checkout out the code of one of my project's dependencies, when I have to fix something.
For use cases where you just run compilation, tests, and produce a test-product against non-released versions of one of your dependencies, I think it is preferable to chose official nightlies over building from source.

So in the context of this ticket I would rather like to bring back published next versions and finding ways to clean them up again after a release.

I think we could add it as a topic for the next dev meeting

[tsmaeder]

I think we're getting to the bottom of our different views: I don't think Theia is just a "dependency" when you build a Theia-base application. It's the framework you live in and debugging through or building against upcoming changes should be a normal part of your routine. Working with Theia is "whitebox", not "blackbox".

[JonasHelming]

@tsmaeder You might have a bias about the last statement. I know many adopting projects, where this is actually not really true. I am also in favor of discussing this in the dev meeting.

[tsmaeder]

@JonasHelming of course I'm biased towards adopters that are also contributors (because they are awesome!). For the rest, it wouldn't make a difference.

[marcdumais-work]

In addition, we would have a template for building applications against theia source, which seems to pose problems for folks, right now.

It's the framework you live in and debugging through or building against upcoming changes should be a normal part of your routine.

I agree that a good example of a setup where this is possible, is needed, and see no better place than here, in Blueprint. cdt cloud blueprint and other extenders will inherit the mechanism. Like Thomas, I feel that those who are both Theia framework extenders and IDE authors are currently left under-served, with no decent example how to handle the intersection. Are they not our best customers?

The easier it is to locally publish/consume arbitrary versions of Theia framework extensions, the easier it will be for IDE authors to try their hand at local Theia enhancements, that can be quickly tried/used in their own app. Easier also for them to give-in the temptation of also becoming Theia framework extenders/contributors. Why use Theia if not to make something at least a bit different? Once that's done and you have something awesome, why maintain all the "nuts-and-bolts" yourself when a community is waiting to do it for you?

I know many adopting projects, where this is actually not really true.

It could be argued that we are doing this, here, so they don't have to. If they do not stray too far from the beaten path, they can do well just watching for recent Blueprint commits, reacting to Theia changes, and follow suite. We do a good job in Blueprint, managing the "intersection", they benefit without further effort on their part.

I mentioned before, one avenue could be to make it easy to publish and consume Theia extensions, in a local registry (e.g. Verdaccio). i.e. in the both the Theia and blueprint repos, make it easy to setup, use and maintain (probably mean frequent wiping of) the local registry. Such a setup provides flexibility, short of the two repositories directly depending on each other.

See the 3rd bullet in the how to test section of this PR for an example of how to manually build theia packages from source and publish them to a local registry, and then build a Theia app (e.g. Blueprint) from the result. It's not very complicated and could be made easier by a small integration (helper scripts) into the Theia and Blueprint repos. Blueprint and Theia should be well aligned in their build environment, which should minimize problems. As soon as they become not well aligned, it's good to know (e.g. requiring newer node version at the Theia level first).

Can this be made to work in GitHub workflows? I think so. Maybe we would need to use GitHub storage to save the local verdaccio registry content, after populating it with a Theia release based on latest master, and restore said storage in the Blueprint build job. Will the job sometimes fail because e.g. Theia master is broken? Probably. I would consider the opportunity to occasionally report such issues upstream, a valid contribution towards the betterment of the framework (i.e. it's not wasted time).

(unfortunately I will not personally have time to spend on this, in the near future)

[jfaltermeier]

To sum up the discussion from the dev meeting:

There are basically two requirements:

1. is to have a nightly build again, but to be able to clean old nightlies
2. is to be able to build against the sources

We want to have both in the end.

For 2. I have opened a separate ticket: #304

We will focus on 1. first.
Initial idea is to offer some containerized solution to build Theia sources and publish them to a configurable npm registry.
For 1. we will have a look at Github, for 2. this may then be Verdaccio. So this should help with both requirements.

For this ticket we want to consume the nightlies from the Github registry then and have an automated way to clean up older nightly versions.

[JonasHelming]

@tsmaeder I think we can close this now