-
Notifications
You must be signed in to change notification settings - Fork 155
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
Publish CLI references #118
Comments
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
I wonder if an easy way to add this would be to support folder in the sync config. |
I've been looking into this and #117, which both require adding a number of generated files generated from a dir to the website. Because files are generated, the sync process will have to add the heading info. These are the options of implementation I could think of:
Pros: compact and easy to maintain configuration
Cons: since the files are generated, the list may change, and will have to be updated every time there is a change, which could be at release time, but also in between release for "pre-release" docs. To be fair, this problem exists today with regular docs, however since they're added by human it's easier to remember to update the sync config
Pros: no full clone of repo, easy to maintain on website side |
(2) seems brittle and tied to GitHub (and how GitHub shows things). What is the "problem" with a full git clone ? 😅 |
Yeah, option (2) is brittle, and would not like that. There is not problem with a full git clone, but sync we may be syncing from 5 or more repos (pipeline, triggers, cli, dashboard, community and in future chains, catalog, hub and more), it would be a full clone of all those, which takes times and resources. We could at least cache repos after the first download to a folder under website so that subsequent runs of the sync command would not need to re-clone. Or we could use git submodules to pull in all those repos via git machinery. |
Oh, I found the github trees API. It's still GitHub specific, but not brittle: Example:
We could first resolve the tag to the sha, using the refs API:
|
Just noting that submodules / subtree would require us to use multiple branches on the website, which I'd prefer to avoid. |
I'm leaning towards option (1), with a command line option to allow specifying a local cache of repos, so that the dev workflow may skip the clone step. |
Add the doc/cmd folder to add the tkn reference docs to the CLI documentation. Add support for defaulting page title and link title to the filename, if not set, which works OK for tkn. Fixes tektoncd#118 Signed-off-by: Andrea Frittoli <[email protected]>
Add the doc/cmd folder to add the tkn reference docs to the CLI documentation. Add support for defaulting page title and link title to the filename, if not set, which works OK for tkn. Fixes tektoncd#118 Signed-off-by: Andrea Frittoli <[email protected]>
Add the doc/cmd folder to add the tkn reference docs to the CLI documentation. Add support for defaulting page title and link title to the filename, if not set, which works OK for tkn. Fixes tektoncd#118 Signed-off-by: Andrea Frittoli <[email protected]>
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
/lifecycle frozen |
Sync is implemented now via local clones, with support for local cache too. |
As part of tekton.dev documentation, we should publish the CLI references of tkn
See https://knative.dev/docs/reference/client/ and https://github.com/tektoncd/cli/tree/master/docs/cmd (reference docs are already generated, we just need to sync them and "present" them)
/kind documentation
The text was updated successfully, but these errors were encountered: