Feature: Last Modified Filter Parameter

[Jdubrick]

Please specify the area for this PR

What does does this PR do / why we need it:
This PR adds an additional filter parameter for stacks/samples on the GET /v2index endpoint.

Changes made include:

• Addition of last_modified.json and lastModified field to test data
• Updated unit tests for proper filtering based on the lastModified parameter
• Logic for creation of index.json to contain lastModified field based off of the last_modified.json created through registry build
• Update to generator schema to reflect new field
• Update to generator index_main.json to ensure last modified field is added correctly

Which issue(s) this PR fixes:

fixes devfile/api#1327

PR acceptance criteria:

• Test Coverage
  • Are your changes sufficiently tested, and are any applicable test cases added or updated to cover your changes?

Documentation (WIP)

• Does the REST API doc need to be updated with your changes?
• Does the registry library doc need to be updated with your changes?

How to test changes / Special notes to the reviewer:
FYI to reviewers: The linked issue has notes for GET /index and GET /v2index. The script that generates last_modified.json that was merged here currently creates this file based on the updated Schema used in v2index where there is a Versions field that contains []Version. For the /index we would need to adjust the script to add the lastModified field to the entire stack as a whole and not just the individual stack versions.

• Go tests should pass for index/generator and index/server
• To test locally you can spin up the registry and perform the following:
  1. GET /v2index?lastModified=2024-04-29 to see more than 1 stack that has this date
  2. GET /v2index?lastModified=2024-04-29&name=<name> to filter even further
  3. GET /v2index/all, GET /v2index/stack GET/v2index/sample to observe the new field added in the response as well

[thepetk]

I've added some comments.

Tried to test the registry viewer against the new devfile-index-base image. I've noticed that some stacks were not visible with the current index. Not sure if there'll be any impact on the current changes and the viewer:

[Jdubrick]

I've added some comments.

Tried to test the registry viewer against the new devfile-index-base image. I've noticed that some stacks were not visible with the current index. Not sure if there'll be any impact on the current changes and the viewer:

Hmm that's interesting, it shouldn't be affecting the default index that is being returned at all. Are you running it with the test data? If so then it is displaying properly as far as I can tell from the screenshot: https://github.com/Jdubrick/registry-support/tree/main/tests/registry

[thepetk]

I've added some comments.
Tried to test the registry viewer against the new devfile-index-base image. I've noticed that some stacks were not visible with the current index. Not sure if there'll be any impact on the current changes and the viewer:

Hmm that's interesting, it shouldn't be affecting the default index that is being returned at all. Are you running it with the test data? If so then it is displaying properly as far as I can tell from the screenshot: https://github.com/Jdubrick/registry-support/tree/main/tests/registry

Oh yes, makes sense my bad. I didn't notice your fork has less stacks :)

[thepetk]

/lgtm and after merging this PR I think we should create & prioritize an issue so the non-versioned stacks can also have the lastModified field with accurate data :)

Very nice feature!

[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

[Jdubrick]

/lgtm and after merging this PR I think we should create & prioritize an issue so the non-versioned stacks can also have the lastModified field with accurate data :)

Very nice feature!

Thanks Fanis! FYI I opened devfile/api#1607 and will work on it once refined