[Cross-Project Epic] CI Build / Weekly Release process should use consistent quay tags for sha-version/next and 7.yy.z/latest

[nickboldt]

Is your task related to a problem? Please describe.

Today we use a harvest medley of terms to describe daily and continuous integration builds across the various Che projects. Some examples include:

• Che Theia uses next to mean continuous integration builds; also pushes a sha-versioned tag

• Che Dashboard used to use next-react to mean "a huge refactoring project that isn't stable yet and will eventually replace the current dashboard, but needs its own fork/branch/tag stream", and next to mean continuous integration builds; does NOT push sha-versioned tags

• Che server uses latest for releases, and nightly for a daily build (last one 14 hrs ago, but last commits 8 hrs ago); does NOT push sha-versioned tags

  • Rename/replace nightly build of che-server with on-push workflow #19894

• Che machine exec uses nightly to mean continuous integration builds; also pushes a sha-versioned tag

• Che devfile registry uses nightly to mean continuous integration builds; also pushes a sha-versioned tag

Describe the solution you'd like

Change to a more consistent naming convention for continuous integration builds, large refactorings, and releases:

• "ci" for "continuously building new images on every commit"
• "next" for "continuously building new images on every commit"
• "next" for special case refactorings (eg., Dashboard Next or Plugin Registry 3.0)
• "nightly" is dead, won't be used anymore as we won't do daily/nightly builds (only CI builds)
• optional "latest" for pointer to 7.yy.z latest released container images (where / if useful)
• sha-versioned tags for all releases and CI builds

In addition to impacting GH action workflows to use different tags, this will impact:

• plugin registry references to :next or :nightly: https://github.com/eclipse/che-plugin-registry/blob/master/che-editors.yaml
• PR checks
• E2E tests

Describe alternatives you've considered

Enjoy the multicultural experience that is guessing what each project means by "nightly", "next", or "latest".

Additional context

[tsmaeder]

"next" for special case refactorings (eg., Dashboard Next or Plugin Registry 3.0)

I don't think it makes sense to have a special tag for those. For starters, there might be multiple of those refactorings going on in parallel (next1, next2)? And second, I think a format like "dashboard_react_ci", etc. would be more descriptive and allow use to have a whole parallel ci/latest/sha, etc. tag stream going.

[nickboldt]

Right but my point is that TODAY, "next" has special meaning and so should not be considered the same as "nightly", when only ONE project uses it for ci builds (che-theia), while everyone else uses nightly.

And so as to offend everyone equally, we can move to "ci" for ALL nightly/next/ci builds, rather than a mix of terms.

[benoitf]

I think nobody understand :ci (as all builds are built by CI anyway (nightlies, per commits, releases, etc. )

Also nextis not only used by theia or che-theia, it's used by all npmjs projects anyway:
https://docs.npmjs.com/about-npm-versions#the-next-release-of-npm

[nickboldt]

Forgot about this thread, so getting back to it now.

• releases are not ci. They are not continuous integration. They are on-request, triggered on a specific date, by a human.

• ci builds (call 'em nightly. integration, per commit, whatever) are continuously built on commits, and are thus CI.

• if next is a convention used by npm projects, and Che is an amalgam of golang, bash, npm, typescript.... could we pick a label that's consistent across the whole project? (eg., machine exec and theia and dashboard all use different tags)? Why make things needlessly complicated? Do we WANT the community to be able to easily contribute, or are we intentionally obfuscating and treating each subproject like its own fiefdom?

[benoitf]

sorry but I find ci counter intuitive about what it contains and when it's built

[benoitf]

having chectl with two channels, one being next and another being stable I would opt-in for next tags on images

[nickboldt]

If everyone is good with :next then I'm happy to start moving the :nightly tags to :next so we're consistent across all of Che.

(Meanwhile in operatorhub, the convention for unreleased content a preview channel, but hey. :) )

[nickboldt]

I've updated my original proposal. How do we like this?

[benoitf]

👍

regarding another topic about multi-arch (and travis usage or not) maybe we'll end up with images having arch suffix as well

I like also about having also sha-versioned tags (it was already there in your proposal)
sometimes current images are broken and it's impossible to get back in time.
Maybe it should be easy to go back in days as well :D like chectl update yesterday / chectl server:deploy

[nickboldt]

Re: the chectl rollback to specific-version (or relative-date) ... probably useful. I've linked to the related rollback issues above.

[dmytro-ndp]

:latest is quite useful for testing pipelines (e.g. che-theia PR check), because we shouldn't change test script to reference latest Che version tag after each release.

[sleshchenko]

Note about:

"next" for "continuously building new images on every commit"

some projects pulls resources from other project, like che-operator(devworkspace, devworkspace-che-operators), chectl (helm charts, che operator deployment).
So, for them on every commit may be not enough. We should keep timeline build (like each hour, nightly) and maybe even an ability to trigger commit manually, when person know that without it Che is going to fail.

[benoitf]

for pulling resources, we can send triggers to other projects as well
like: new che-server commit : trigger a new chectl release to include these new deployments

[nickboldt]

Starting this week, we'll start removing the :nightly tags from the release process and from quay.

[nickboldt]

Status:

• configbump - n/a
• operator
• dashboard - rename https://github.com/eclipse-che/che-dashboard/tree/main/.github/workflows/ci*.yaml for consistency
• devfile reg
• devfile reg sidecars - no new nightly being created, but old images still need to be deleted from quay
• intellij sidecar - rename https://github.com/che-incubator/jetbrains-editor-images/blob/main/.github/workflows/master.yml
• DWO - rename https://github.com/devfile/devworkspace-operator/blob/main/.github/workflows/dockerimage-next.yml to be consistent w/ other repos
• DWCO - remove :ci tag from https://github.com/che-incubator/devworkspace-che-operator/blob/main/.github/workflows/build-image.yml#L29
• KIP, KIPO
• jwtproxy - n/a
• machine-exec
• plugin brokers - n/a
• plugin reg
• che server
• theia dev, theia, endpoint, vsix installer

Additionally, it seems many projects use a different naming convention for its :next build action file, and as part of this epic we should clean that up too, so where it makes sense, we have next-build.yml in all (most) of the projects.

next-build:

• che/.github/workflows/next-build.yml
• che-devfile-registry/.github/workflows/next-build.yml
• che-plugin-registry/.github/workflows/next-build.yml
• che-kubernetes-image-puller/.github/workflows/next-build.yml
• che-machine-exec/.github/workflows/next-build.yaml
• che-operator/.github/workflows/next-build.yaml
• che-server/.github/workflows/next-build.yml

Other variations:

• devworkspace-che-operator/.github/workflows/build-image.yml
• che-editor-intellij-community/.github/workflows/build-publish.yml
• che-jwtproxy/.github/workflows/build.yml
• che-dashboard/.github/workflows/ci.yaml
• che-dashboard/.github/workflows/ci-multiarch.yaml
  etc.

[nickboldt]

Done:

• KIP
• Dashboard
• DWCO

Still to do for consistency:

• https://github.com/eclipse/che-jwtproxy/blob/main/.github/workflows/build.yml#L81 uses :latest but no :next ; rename to next-build.yml
• intellij sidecar - rename https://github.com/che-incubator/jetbrains-editor-images/blob/main/.github/workflows/master.yml
• DWO - rename https://github.com/devfile/devworkspace-operator/blob/main/.github/workflows/dockerimage-next.yml to be consistent w/ other repos
• devfile reg sidecars - delete old nightly image tags from quay
• KIPO - Remove 'nightly' / 'master' ci-centos CI for kubernetes-image-puller-operator #20149

And then we need to purge the old :nightly tags to avoid confusion (from all the other projects)

[ibuziuk]

regarding #20149
@mkuznyetsov @nickboldt do you plan to provide an MR with the new CI based on the GH actions to https://github.com/che-incubator/kubernetes-image-puller-operator ?

[mkuznyetsov]

che-antora-2.3:nightly
che-cpp-rhel7:nightly
che-dotnet-2.2:nightly
che-dotnet-3.1:nightly
che-golang-1.12:nightly
che-golang-1.14:nightly
che-java11-gradle:nightly
che-java11-maven:nightly
che-java8-maven:nightly
che-nodejs10-community:nightly
che-nodejs12-community:nightly
che-nodejs10-ubi:nightly
che-nodejs8-centos:nightly
che-php-7:nightly
che-python-3.8:nightly
che-quarkus:nightly
che-rust-1.39:nightly

the following sidecar images have been deleted from Quay.io