Uploaded image for project: 'Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces) '
  1. Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces)
  2. CRW-1648

Support upstream plugin update automation in CRW

XMLWordPrintable

    • False
    • False
    • Hide
      = Support upstream plug-in update automation

      // Cause:
      The plug-in `id` fields no longer contain the plug-in's version. Instead, all plug-in `id` fields use `latest` to denote the plugin version. For example: `golang/go/0.16.1` becomes `golang/go/latest`.

      // Consequence:
      Some devfiles may not start and will need to be revised. If a devfile was dependent on a specific plugin version in the `id` field, then changing the version to `latest` is required.

      // Result:
      Devfiles will start as expected. Manually manipulating plugin versions in the `id` field is no longer supported.
      Show
      = Support upstream plug-in update automation // Cause: The plug-in `id` fields no longer contain the plug-in's version. Instead, all plug-in `id` fields use `latest` to denote the plugin version. For example: `golang/go/0.16.1` becomes `golang/go/latest`. // Consequence: Some devfiles may not start and will need to be revised. If a devfile was dependent on a specific plugin version in the `id` field, then changing the version to `latest` is required. // Result: Devfiles will start as expected. Manually manipulating plugin versions in the `id` field is no longer supported.

      In https://github.com/eclipse/che/issues/15819 work has begun to streamline the update process for the plugin registry, including:

      We should enable the same behaviour in CRW so that we can also generate and validate PRs for plugin updates.

      HOWEVER...

      we should also remove all digests from meta.yaml and devfile.yaml so that we no longer have to rebuild the registry EVERY TIME a referenced container is rebuilt. Why? Because without this we'll never be able to use Freshmaker to respin containers for CVEs automatically, and will forever have to manage security issues manually.

      Failing that, could we use the RELATED_IMAGE_* env vars from the operator metadata's CSV? that way we only have a single manifest of the images, and don't have to have digests hardcoded in multiple places.

        1. Screenshot_20210624_112816.png
          Screenshot_20210624_112816.png
          14 kB

          1.
          		 transform upstream icons, strings to work for downstream Sub-task Closed Critical Eric Williams
          2.
          		 update bootstrapping process to fetch vsix files into a tarball, then unpack them during brew build Sub-task Closed Critical Eric Williams
          3.
          		 migrate CRW 2.8 plugin reg build/scripts/list_referenced_images.sh so that it works w/ new CRW 2.9 format Sub-task Closed Critical Eric Williams
          4.
          		 generated che-editors.yaml downstream contains reference to invalid che-theia image Sub-task Closed Critical Nick Boldt
          5.
          		 cannot install yarn during a brew build (must use previously committed binary) Sub-task Closed Major Eric Williams
          6.
          		 cannot "anaylze" vsix files on github or download.jboss.org during brew build Sub-task Closed Major Eric Williams

              ericwill@redhat.com Eric Williams
              nickboldt Nick Boldt
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: