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

          There are no Sub-Tasks for this issue.

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

                Created:
                Updated:
                Resolved: