Argo-cd: Possible release process for argo-ui

[tetchel]

ArgoCD always pulls the master version of argo-ui (link), which is somewhat risky if breaking changes go into argo-ui. Consequently, argo-ui master has to be highly stable.

Short of a proper release cycle, one easy way to stabilize this dependency is to create a "stable" branch which is manually rebased on the development branch. The development branch in GitHub terms would be the 'main' branch - the one PRs are targeted against by default. Currently, the master branch is both the development and stable branch.

This manual rebase can be done periodically (eg weekly) or whenever the maintainer feels the development branch contains changes that are safe/stable enough.

The advantage of this approach is a relatively cheap separation between stable and latest code on argo-ui, which allows low-cost "releases" that do not require updating any code in the projects that depend on argo-ui, since those projects are already targeting the stable branch. This reduces the testing overhead required for individual argo-ui PRs, since the stability of the development branch can be "lower".

The disadvantage of this approach is that it requires significant attention from a maintainer whose job it is to periodically rebase the stable branch on the development branch. The cost of reducing testing for individual PRs means that the testing is now batched into these periodic rebases, so the testing pre-rebase should be extensive.

The naming of the dev/stable branches is subjective. I would personally suggest leaving master as the dev/main branch and creating a new stable branch, eg stable, or release.

[RichiCoder1]

Is there a reason not to publish the UI project as a normal NPM package, and then automate bumping it via Dependabot/Renovatebot? It wouldn't be as seamless, but it align more nicely with how other projects tend to manage this short of thing.

[tetchel]

I think the reason it is not versioned right now is because the only consumers of argo-ui are argo CD and workflows, which basically always want the latest version and can test for regressions easily enough.

So, the overhead of deciding when to release, tagging, packaging, and publishing is not worth the effort.

[alexmt]

I think publishing to NPM is the next step. The creation of release branch allows us to "batch" testing work that is required to upgrade Argo CD/Argo Workflows UI. In addition to that, we can configure CI to build and publish every commit of release branch to NPM. The version might be inferred from e.g. VERSION file that is manually managed.

[RichiCoder1]

Both semantic-release and auto are pretty great at making that process nice and trivial. Latter especially if you wanna batch changes instead of just continuously releasing.

[alexmt]

Seems like no one has objections about your proposal @tetchel .

As a first step we can introduce stable/release branch. I would prefer release ( stable makse it sound like master branch is not stable). Next we can automate publishing to NPM using semantic-release or auto, as @RichiCoder1 is proposing.

What do you think?