Enhance the `draft info` output
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 30/100
Research direction
Start with the draft info command and compare its current JSON output with the proposed Azure Portal-like structure. Done means exposing version display names, image and builder versions, default ports, and a broader version selection for supported languages.
Written by the indexing model from the issue text.
Description
Is your feature request related to a problem? Please describe.
It would be really nice if the info command could provide enough information to build an experience like that of the Azure Portal:
In the above, selection of a language version allows consumers to infer both runtime and builder images, as well as a default port.
Mention what platform you want to support the new feature
All
Describe the solution you'd like
Currently, Draft outputs this (to take Java as an example):
{
"name": "java",
"displayName": "Java",
"variableExampleValues": {
"BUILDERVERSION": [
"3-jdk-11"
],
"VERSION": [
"8-jre",
"11-jre",
"17-jre",
"19-jre"
]
}
But an Azure Portal-like experience would require something like this:
{
"name": "java",
"displayName": "Java",
"defaultPort": 8080,
"versions": [
{
"name": "Java 8",
"imageVersion": "8-jre",
"builderVersion": "3-eclipse-temurin-8"
},
{
"name": "Java 11",
"imageVersion": "11-jre",
"builderVersion": "3-eclipse-temurin-11"
},
{
"name": "Java 17",
"imageVersion": "17-jre",
"builderVersion": "3-eclipse-temurin-17"
},
{
"name": "Java 19",
"imageVersion": "19-jre",
"builderVersion": "3-eclipse-temurin-19"
},
]
}
I.e. in addition to the current output, it would also allow consumers to extract:
- A display name for each of the versions
- An image version for each of the versions
- A builder version for each of the versions (if required in the Dockerfile)
- A default port for the language
- A more comprehensive selection of versions (e.g. for
go, theinfocommand outputs1.16..1.19, yet the Portal displays1.15..1.20)
Describe alternatives you've considered
As a consumer of Draft, I can maintain my own JSON mapping of languages to versions and ports, just as the Portal has to.
Additional context
I understand that maintaining a list of available versions (and associated images for each) is a maintenance overhead, but if Draft doesn't do that then consuming tools all have to, meaning it's hard to keep them in sync.
- Dominant language
- Go
- Stars
- 644
- Forks
- 74
- PR merge metrics
- No merged PRs in 30d
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/draft
-
Difficulty 3/5 1-2 days Newbie friendliness 38/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 42/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
Difficulty 1/5 Under an hour Newbie friendliness 84/100
-
enhancement needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
kind/cleanup
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
kubernetes-sigs/kueue#15947 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sympozium-ai/sympozium#627 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100