feat: added registry_url query param to /osm/api/registry-info endpoint#311
Open
sissl0 wants to merge 1 commit into
Open
feat: added registry_url query param to /osm/api/registry-info endpoint#311sissl0 wants to merge 1 commit into
sissl0 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
/osm/api/registry-infoendpoint previously could only return info about the embedded registry. Custom registry sources could only be configured at install time via theregistry_urlfield in the POST body of/osm/api/registry-install.This PR exposes
registry_urlas a query parameter on the GET endpoint so callers can point the info endpoint at a custom registry URL or local file path without making a separate install request. The description and docs were adjusted as well.The
customHeadersfield forLoadRegistrywas not implemented, onlypathOrURL.Implemented for both registry modes:
direct-fetch(default) : Replaces the full binary list source (URL or file path)nix-build: Used as a metadata overlay —desc,tags,version,repo_linkfor each toolChanges
pkg/server/handlers/install.goGetRegistryInfo: updated swagger annotation — addedregistry_urlquery param with dual-mode description.getDirectFetchRegistry: already readregistry_urlfrom the query; no logic change.getNixBuildRegistry: now readsregistry_urlfrom the query and passes it toinstaller.LoadRegistryfor the metadata overlay. The field is included in the JSON response.docs/api-swagger/swagger.yamlregistry_urlquery parameter entry toGET /osm/api/registry-infowith the dual-mode description.docs/api-swagger/swagger.jsonswagger.yaml(JSON counterpart).docs/api-swagger/docs.goswagger.yaml(Go-embedded counterpart).docs/api/install.mdxregistry_urlrow in the Query Parameters table to describe both modes.registry_urlusage example under the Nix-Build Mode section.registry_urlfield to the Nix-Build Response Fields table.test/e2e/api_test.gonet/url,path/filepath,runtime.getPresetRegistryPath— resolves the path topublic/presets/registry-metadata-direct-fetch.jsonrelative to the test file.testRegistryEndpointwith four sub-cases:registry_url).registry_urlin direct-fetch mode — verifiesregistry_urlis echoed back andbinariescontains known entries (amass,nuclei).registry_url— verifiesnix_installed,categories, andregistry_urlfields are present.registry_url— verifiesregistry_urlis echoed back.Affected Files
Test Output
The build was successful and tests returned no errors.