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