Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tool description sourced from tool version can involve guesswork #244

Open
denis-yuen opened this issue Sep 13, 2023 · 2 comments
Open

Tool description sourced from tool version can involve guesswork #244

denis-yuen opened this issue Sep 13, 2023 · 2 comments

Comments

@denis-yuen
Copy link
Member

denis-yuen commented Sep 13, 2023

Tools have a description
https://github.com/ga4gh/tool-registry-service-schemas/blob/v2.0.1/openapi/openapi.yaml#L552-L560

Tools have a version specific description queued up
1dd4bf8

This may be implementation specific but could be a common issue. In Dockstore, the tool-level description is sourced from a default version of the tool that has been picked to "present" to end-users, kind of like the default branch feature in GitHub.
However this version is not indicated to end users in TRS. This can lead to broken links in the description since the description may have relative links to other workflows

An example is https://dockstore.org/api/ga4gh/trs/v2/tools/%23workflow%2Fgithub.com%2FPacificBiosciences%2Fwdl-humanwgs%2Fwdl-humanwgs

Possible solutions:

TRS-related:

  • is the concept of a "default" version of general interest/relevant beyond Dockstore?
  • should there be better documentation on how the toolversion specific descriptions relate to the tool level descriptions?

┆Issue is synchronized with this Jira Story
┆Project Name: Zzz-ARCHIVE GA4GH tool-registry-service
┆Issue Number: TRS-68

@denis-yuen
Copy link
Member Author

Another possible solution is to present a path as an additional property for a tool for which to resolve the relative path links

@uniqueg
Copy link
Collaborator

uniqueg commented Sep 14, 2023

  1. I can see a default version being useful, especially if SemVer is not followed by the tool.
  2. Better documentation is often a good idea, or always, if it's really better :)

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

No branches or pull requests

2 participants