Update generation script to handle non-versioned items

[Jdubrick]

What does this PR do?:

Summarize the changes. Are any stacks or samples added or updated?

This PR contains the changes required to the generate_last_mod_file.sh script to allow for the last_modified.json to properly contain stacks/samples that do not have a version. In the case of a non-versioned item the version field in the json will be "null".

For samples the parsing handles the following 3 cases:

1. Versioned sample
2. Non-versioned sample that has a git branch preference (revision)
3. Non-versioned sample that has no git branch preference (defaults to main)

Example output:

{
  "stacks": [
    {
      "name": "dotnet50",
      "version": "1.0.4",
      "lastModified": "2024-05-14T17:06:30+03:00"
    },
    {
      "name": "dotnet60",
      "version": "1.0.3",
      "lastModified": "2024-07-22T15:33:17+02:00"
    },
    {
      "name": "dotnetcore31",
      "version": "1.0.3",
      "lastModified": "2024-05-27T15:44:32+03:00"
    },
    {
      "name": "go",
      "version": "1.0.2",
      "lastModified": "2023-11-08T12:54:08+00:00"
    },
   ....
  ],
  "samples": [
    {
      "name": "nodejs-basic",
      "version": "3.0.0",
      "lastModified": "2024-06-05T15:26:11-04:00"
    },
    .....
    {
      "name": "test-basic",
      "version": "null",
      "lastModified": "2024-04-18T10:30:44+01:00"
    },
    {
      "name": "test-basic-revision",
      "version": "null",
      "lastModified": "2024-04-18T10:30:44+01:00"
    }
  ]
}

Which issue(s) this PR fixes:

Link to github issue(s)

fixes devfile/api#1607

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:

To test the changes you will need to do the following:

1. Update extraDevfileEntries.yaml locally to contain samples that do not have versions. You can reference the ones I used here:

- name: test-basic
    displayName: Basic Python
    description: A simple Hello World application using Python
    icon: https://www.python.org/static/community_logos/python-logo-generic.svg
    tags: ["Python"]
    projectType: python
    language: TEST
    git:
      remotes:
        origin: https://github.com/devfile-samples/devfile-sample-python-basic.git
  - name: test-basic-revision
    displayName: Basic Python
    description: A simple Hello World application using Python
    icon: https://www.python.org/static/community_logos/python-logo-generic.svg
    tags: ["Python"]
    projectType: python
    language: TEST
    git:
      revision: main
      remotes:
        origin: https://github.com/devfile-samples/devfile-sample-python-basic.git

2. Create a new stack that has a devfile within it that has no version. In order for this stack to be properly read (since it parses git logs for the changed date) you will need to locally commit the addition of this stack so it appears in the git log.
3. Run .ci./generate_last_mod_file.sh and observe the changes in last_modified.json.

[thepetk]

Nice addition! Only questions is if we could add null instead of "null" as value in the json file. Other than that lgtm

[thepetk]

I've also tested locally and it works as expected.

[Jdubrick]

Nice addition! Only questions is if we could add null instead of "null" as value in the json file. Other than that lgtm

I was thinking that as well. It seems like when during the parse everything is parsed as a string but it worked out because on the index/generator side the version (in this case "null" whereas usually it'd be "x.x.x") is a string key in a map.

It being in string format instead of just null allows us to keep using that setup for the index/generator side, wdyt?

@thepetk

[thepetk]

Nice addition! Only questions is if we could add null instead of "null" as value in the json file. Other than that lgtm

I was thinking that as well. It seems like when during the parse everything is parsed as a string but it worked out because on the index/generator side the version (in this case "null" whereas usually it'd be "x.x.x") is a string key in a map.

It being in string format instead of just null allows us to keep using that setup for the index/generator side, wdyt?

@thepetk

thinking only it might be better to use another key-word like "undefined" just to avoid potential confusion with "null" vs null wdyt?

[Jdubrick]

Nice addition! Only questions is if we could add null instead of "null" as value in the json file. Other than that lgtm

I was thinking that as well. It seems like when during the parse everything is parsed as a string but it worked out because on the index/generator side the version (in this case "null" whereas usually it'd be "x.x.x") is a string key in a map.
It being in string format instead of just null allows us to keep using that setup for the index/generator side, wdyt?
@thepetk

thinking only it might be better to use another key-word like "undefined" just to avoid potential confusion with "null" vs null wdyt?

I replaced "null" with "undefined". I will make the appropriate changes to reflect that in devfile/registry-support#250 as well

Changes to other PR: devfile/registry-support@1fadd41

[Jdubrick]

/retest

[thepetk]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Jdubrick, 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:

• OWNERS [Jdubrick,thepetk]

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