Update nodejs-nuxtjs stack

[RomanNikitenko]

What does this PR do?:

Updates nodejs-nuxtjs stack:

• Add new version: 1.2.1
• Set schemaVersion: 2.2.2
• Set https protocol for the endpoint
• Set 1.2.1 version as a default one

Which issue(s) this PR fixes:

eclipse-che/che#22869

PR acceptance criteria:

• Contributing guide
  Have you read the devfile registry contributing guide and followed its instructions?
• Test automation
  Does this repository's tests pass with your changes?
• Documentation
  Does any documentation need to be updated with your changes?
• Check Tools Provider
  Have you tested the changes with existing tools, i.e. Odo, Che, Console? (See devfile registry contributing guide on how to test changes)

How to test changes / Special notes to the reviewer:

You can use the following link to start a workspace for testing:
https://workspaces.openshift.com/#https://raw.githubusercontent.com/RomanNikitenko/registry/update-nuxtjs/stacks/nodejs-nuxtjs/1.2.1/devfile.yaml

Signed-off-by: Roman Nikitenko rnikiten@redhat.com

rh-pre-commit.version: 2.2.0
rh-pre-commit.check-secrets: ENABLED

[openshift-ci]

Hi @RomanNikitenko. Thanks for your PR.

I'm waiting for a devfile member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[RomanNikitenko]

I see that 2.2.2 is in the list of supported versions.
At the same time tests fail with the error:
error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0

So, version 2.2.2 is still not supported?

[Jdubrick]

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error: error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0

So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.

See:

registry/tests/validate_devfile_schemas/go.mod

Line 6 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

registry/tests/odov3/go.mod

Line 7 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

devfile/library@44ca18d

cc @michael-valdron @thepetk

[Jdubrick]

I believe this open issue would cover the changes required to unblock these ci checks? @michael-valdron
devfile/api#1479

[thepetk]

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error: error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.

See:

registry/tests/validate_devfile_schemas/go.mod

Line 6 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

registry/tests/odov3/go.mod

Line 7 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

[michael-valdron]

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

We can do this to unblock this PR and update to v2.2.2 release itself once @Jdubrick has completed devfile/api#1477 to resolve devfile/api#1479.

[Jdubrick]

/retest

[michael-valdron]

@Jdubrick we'll need to rebase to your changes

FYI @RomanNikitenko

[thepetk]

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error: error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:

registry/tests/validate_devfile_schemas/go.mod

Line 6 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

registry/tests/odov3/go.mod

Line 7 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Digged a little bit further for this issue and opened devfile/api#1494. We should also update the version of library used by odo in order to be able to support v2.2.1 and v2.2.2 in our PR checks

Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for #342

cc @michael-valdron @Jdubrick

[thepetk]

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error: error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:

registry/tests/validate_devfile_schemas/go.mod

Line 6 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

registry/tests/odov3/go.mod

Line 7 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Digged a little bit further for this issue and opened devfile/api#1494. We should also update the version of library used by odo in order to be able to support v2.2.1 and v2.2.2 in our PR checks

Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for #342

cc @michael-valdron @Jdubrick

I've merged the temporary fix and now the check should be passing

[thepetk]

I see that 2.2.2 is in the list of supported versions. At the same time tests fail with the error: error parsing devfile because of non-compliant data due to unable to find schema for version "2.2.2". The parser supports devfile schema for version v1alpha2, 2.0.0, 2.1.0, 2.2.0
So, version 2.2.2 is still not supported?

@RomanNikitenko I believe that the CI tests for validating the stacks aren't updated to the latest commit hash that would contain the change to devfile library that increased the supported schema versions. I will open an issue so that we can update those hashes and get this unblocked for you.
See:

registry/tests/validate_devfile_schemas/go.mod

Line 6 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

registry/tests/odov3/go.mod

Line 7 in 72a45de

github.com/devfile/library/v2 v2.2.2-0.20240311165050-d3c277078874

devfile/library@44ca18d
cc @michael-valdron @thepetk

Yes I think that the check_odov3 and validate_devfile_schemas tests should be bumped up to commit 44ca18d63cf41ff4d5f8a64c87453f905d2598e5 of library so we can take advantage of the support to those schemaVersions

Digged a little bit further for this issue and opened devfile/api#1494. We should also update the version of library used by odo in order to be able to support v2.2.1 and v2.2.2 in our PR checks
Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for #342
cc @michael-valdron @Jdubrick

I've merged the temporary fix and now the check should be passing

Might need a rebase @RomanNikitenko :(

[michael-valdron]

Another question is if we would like to remove the 1.2.0 version completely (dir and stack.yaml record) like we did for #342

@thepetk #347 (comment)

[thepetk]

/retest

[RomanNikitenko]

Please let me know if any changes are required on my part to merge

[thepetk]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: RomanNikitenko, thepetk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• stacks/OWNERS [thepetk]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment