Skip to content

Add list-all-resources endpoint#7

Merged
BobbyRBruce merged 3 commits intogem5:add-list-resources-endpointfrom
Harshil2107:add-list-resources-end-point
Dec 23, 2025
Merged

Add list-all-resources endpoint#7
BobbyRBruce merged 3 commits intogem5:add-list-resources-endpointfrom
Harshil2107:add-list-resources-end-point

Conversation

@Harshil2107
Copy link
Copy Markdown
Collaborator

  • Add list all resources endpoint
  • Add unit tests for the new endpoint
  • Update readme with information about the new endpoint

- Add list all resources endpoint
- Add unit tests for the new endpoint
- Update readme with information about the new endpoint
@Harshil2107
Copy link
Copy Markdown
Collaborator Author

Note: The CI tests will fail in this PR as the ENV variables needed to run the tests will not work when PR is from a fork.

Once the changes look good I will merge this PR to the add-list-resources-endpoint branch on this repo and open another PR to main so that we can run the CI tests on github.

@BobbyRBruce
Copy link
Copy Markdown
Member

Note: The CI tests will fail in this PR as the ENV variables needed to run the tests will not work when PR is from a fork.

Once the changes look good I will merge this PR to the add-list-resources-endpoint branch on this repo and open another PR to main so that we can run the CI tests on github.

Just before I start reviewing, and while I remember: Why do you do things this way? Why are you doing a PR for your changes into a feature branch then a PR for the feature branch into the main? Why not just a PR from your changes into the main?

@Harshil2107
Copy link
Copy Markdown
Collaborator Author

Note: The CI tests will fail in this PR as the ENV variables needed to run the tests will not work when PR is from a fork.
Once the changes look good I will merge this PR to the add-list-resources-endpoint branch on this repo and open another PR to main so that we can run the CI tests on github.

Just before I start reviewing, and while I remember: Why do you do things this way? Why are you doing a PR for your changes into a feature branch then a PR for the feature branch into the main? Why not just a PR from your changes into the main?

For our CI tests we run the functions locally on the action so we need MongoDB seceret and Azure search secrets. The CI tests will only use those secrets when a PR is made from the same repo and not any forks.

I do it this way as I can have the feature related changes on my fork, as I donr want to directly push to this repo.

Copy link
Copy Markdown
Member

@BobbyRBruce BobbyRBruce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My only big question is, should 'list_all_resources' return literally all gem5-resources with listed compatibility even if many of those are the same resource ID differentiated with different versions? If resource X has 100 versions, all of which are listed as compatibility with a given gem5 version, should it return 100. Is there ever a case where we want this or its desired? Maybe, but it'd be easier if I could get it filtered to just the latest versions of each resource ID and save me the post-processing.

I'm thinking maybe you could have an additional part of the query which turns this filtering on or off. perhaps just a flag, 'latest-compatible-versions', that if set does this server-side

Comment thread README.md Outdated
Comment thread README.md
Comment thread functions/list_all_resources.py Outdated
Comment thread functions/list_all_resources.py
Comment thread functions/list_all_resources.py
@BobbyRBruce
Copy link
Copy Markdown
Member

Note: The CI tests will fail in this PR as the ENV variables needed to run the tests will not work when PR is from a fork.
Once the changes look good I will merge this PR to the add-list-resources-endpoint branch on this repo and open another PR to main so that we can run the CI tests on github.

Just before I start reviewing, and while I remember: Why do you do things this way? Why are you doing a PR for your changes into a feature branch then a PR for the feature branch into the main? Why not just a PR from your changes into the main?

For our CI tests we run the functions locally on the action so we need MongoDB seceret and Azure search secrets. The CI tests will only use those secrets when a PR is made from the same repo and not any forks.

I do it this way as I can have the feature related changes on my fork, as I donr want to directly push to this repo.

Ok, that resulted in me taking too big a dive into GitHub actions; but yes, it seems you're right. I feel like this limitation should be fixed by Github at some point but yes. Thanks for explaining it to me!

- Add the `latest-version` param that if set tp true will return only the latest compatible version of the resource. False by default

- Add unit tests to test the  `latest-version` param

- Update readme with information about the  `latest-version` param
BobbyRBruce pushed a commit to gem5/gem5 that referenced this pull request Dec 23, 2025
)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
@BobbyRBruce BobbyRBruce merged commit f8915c7 into gem5:add-list-resources-endpoint Dec 23, 2025
1 of 2 checks passed
BobbyRBruce pushed a commit to gem5/gem5 that referenced this pull request Dec 30, 2025
)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
pranith pushed a commit to pranith/gem5 that referenced this pull request Jan 7, 2026
…m5#2826)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
Harshil2107 added a commit that referenced this pull request Jan 8, 2026
* Add list-all-resources endpoint

- Add list all resources endpoint
- Add unit tests for the new endpoint
- Update readme with information about the new endpoint

* Update Readme to clarify gem5 version format

* Add an optional `latest-version` param to `list_all_resources`

- Add the `latest-version` param that if set tp true will return only the latest compatible version of the resource. False by default

- Add unit tests to test the  `latest-version` param

- Update readme with information about the  `latest-version` param
mhfuzun pushed a commit to mhfuzun/gem5-test-1 that referenced this pull request Jan 19, 2026
…m5#2826)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
erin-le pushed a commit to erin-le/gem5 that referenced this pull request Feb 27, 2026
…m5#2826)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
tingtong02 pushed a commit to tingtong02/gem5_learning that referenced this pull request Apr 15, 2026
…m5#2826)

This PR fixes the `list_resources` function in `client.py` by adding a
function that points to a new endpoint on azure functions.

This PR is dependant on
gem5/resources-azure-api#7 as this PR adds the
endpoint that is called by the updated `list_resources` function.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants