Closed osslate closed 1 month ago
OO until Monday but just wanted to mention that the MD files won't live on download.daytona.io. They should only be fetched from Daytona's Github. If you need directory listing, you can use Github's API.
I can help you out with that on Monday.
@Tpuljak sounds good, I'll look into it more in the meantime.
The workflow thought of here is, once a new Daytona release is tagged --- and before the corresponding docs release goes out:
So this is essentially the last step on my end before a new docs release is tagged and pushed to prod. I'm fine leaving it in ./tools
as it's directly related to the docs publication process, and it also caters for customizing the Markdown before/after the autogenerated stuff (which we'll use later).
There might be a way to automate it in the future, but we don't need to worry about it for now.
There might be a way to automate it in the future, but we don't need to worry about it for now.
Okay, let's leave it for now but I would def recommend we automate this because it seems very "automatable" if that makes sense 😄
inconsistent "option" markdown, some are code some are bash. not sure which is best @Tpuljak can weigh in
Missing overview text
Not sure if these are useful; daytona Daytona is a Dev Environment Manager
Synopsis Daytona is a Dev Environment Manager
daytona
command does something, even if the autogenerated docs aren't useful in it's current form. Since these are generated based on docs living in @daytonaio/daytona, I'll also start sending PRs there to make the CLI docs more useful, and gradually, the docs published here will follow.I'll open an issue over in @daytonaio/daytona to update these docs for now. In the future, updates to the autogenerated CLI reference should probably go over to @daytonaio/daytona as that's where they live, but opening up to @Tpuljak @idagelic for feedback
I'll open an issue over in @daytonaio/daytona to update these docs for now. In the future, updates to the autogenerated CLI reference should probably go over to @daytonaio/daytona as that's where they live, but opening up to @Tpuljak @idagelic for feedback
That is correct - anything that gets "autogenerated" comes from the main repo and all the descriptions of commands/flags etc. may be changed so if you've got recommendations, just open up an issue.
@ivan-burazin fixed the first 2 issues
- daytona - Daytona is a Dev Environment Manager. true daytona is a command as such there should be text ecpain what it does, this is just the title
I agree it needs to be updated. As mentioned in https://github.com/daytonaio/docs/pull/40#issuecomment-2145577937 and https://github.com/daytonaio/docs/pull/40#issuecomment-2145600838, the generated documentation comes directly from Daytona's CLI. In order to update that, we need to submit a PR to the Daytona repo. Whatever you get with daytona --help
commands is what becomes the docs here.
I'll open a PR to improve the CLI docs, but it won't filter down to the docs site until they're accepted there by Toma/Ivan/Luka and until they become part of a new Daytona release.
- Synopsis Daytona is a Dev Environment Manager. what is Synopsis what does this mean?
I believe the "Synposis" part is generated from one of the "Short" or "Long" descriptions defined here. https://github.com/daytonaio/daytona/blob/main/pkg/cmd/cmd.go#L26-L32
Maybe @Tpuljak or @idagelic have an idea of why this section is generated.
- CLI overview, should be have a bit more fluff. suggest a paragraph for every overview
Is there anything in particular you'd add to the intro? Generally with documentation, the objective is to avoid fluff and focus on getting to the point. I'm not sure what else to add in the intro that's useful for users, but open to suggestions :)
- missing core command but has options; daytona container-registry,daytona git-providers...possibly others
Could you clarify? I can see doc entries for both daytona container-registry
and daytona git-providers
:
I believe the "Synposis" part is generated from one of the "Short" or "Long" descriptions defined here. https://github.com/daytonaio/daytona/blob/main/pkg/cmd/cmd.go#L26-L32
Maybe @Tpuljak or @idagelic have an idea of why this section is generated.
That is correct - the synopsis part is generated from the "Long" description. In the CLI it appears when you run a specific command's --help
.
Removing the "long" description also removes the synopsis (as well as the heading). Let me know what you want to have there in an issue on the main repo.
I believe the "Synposis" part is generated from one of the "Short" or "Long" descriptions defined here. https://github.com/daytonaio/daytona/blob/main/pkg/cmd/cmd.go#L26-L32 Maybe @Tpuljak or @idagelic have an idea of why this section is generated.
That is correct - the synopsis part is generated from the "Long" description. In the CLI it appears when you run a specific command's
--help
. Removing the "long" description also removes the synopsis (as well as the heading). Let me know what you want to have there in an issue on the main repo.
Its fin that the CLI has this, but it makes no sense in the cli, so would just script it to be removed
@osslate needs more context, people don't know anything about Daytona when landing here as such it next to convey what this is as much as possible.
missing commands ![Uploading Screenshot 2024-06-04 at 15.53.03.png…]()
@osslate lmk when to review again.
Closes #22.
This PR adds a CLI reference generation script based on the export from Cobra. The CLI reference for 0.16.x looks like this:
Areas of future improvement
.md
files from the export live in<REPO>/tmp/cli-docs/
.