-
Notifications
You must be signed in to change notification settings - Fork 25
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
Import documentation #27
Import documentation #27
Conversation
@adambkaplan thoughts? |
/kind documentation |
Can we just link the document from I think they are duplicates and we have to update/maintain them if there is any update on the shipwright/build side (I think it will happen frequently this year.) |
@zhangtbj I share your concern about having duplicate docs. shipwright.io is our user-facing website, therefore user-facing documentation should live there long term. We can flip our contributing guide and ask new features to have PRs opened against shipwright-io/website. Upstream Kubernetes is large enough that a dedicated SIG tracks features and helps draft docs [1]. At our state is to too much to ask developers to draft feature docs? [1] https://kubernetes.io/docs/contribute/new-content/new-features/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sftim thank you for the PR!
I noticed that the api docs don't generate their own sub-level in the sidebar, so for now everything is under one level. I think if you add _index.md
files in the subfolders, we get those sub-headers for free?
Regarding segments, I think for this initial import we can split into two:
- "Concepts"
- "Configuration"
The latter exposes a lot of fine tuning that a new Shipwright user would not necessarily use.
P.S. miss you from sig-docs, as you can see I've been busy lately 👋.
@@ -3,20 +3,136 @@ title: "Documentation" | |||
linkTitle: "Documentation" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self - the imported article is a true overview. In the long term we will want this page to serve as a table of contents, so keeping the "Documentation" title is appropriate.
@@ -0,0 +1,170 @@ | |||
--- | |||
title: Authentication during builds |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this too can live under "concepts"
content/en/docs/controller_flow.md
Outdated
title: Control flow | ||
--- | ||
|
||
The following image illustrate the interactions between the Build, BuildRun controller and the Tekton Pipeline controller: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a bit more of an architecture article, and not meant for end users. For now I say it can live in shipwright-io/build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok cool.
@@ -0,0 +1,84 @@ | |||
--- | |||
title: Build Controller Metrics |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this is geared towards installation/configuration of the controller. More is coming in this regard as we are tuning our installation process.
@@ -0,0 +1,40 @@ | |||
--- | |||
title: Build Controller Profiling |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Likewise, this is an install/configuration article.
@@ -0,0 +1,23 @@ | |||
--- | |||
title: "Configuration" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an install/configuration article
Not super easily. Hugo Markdown and the documentation in I agree with #27 (comment) about migrating docs to this repo (so: remove the Markdown pages from the other repo when this goes live). If you keep them in the other repo, you need to trigger some kind of dependent Netlify build when PRs in |
BTW, I've marked this PR to allow maintainer edits. Please feel free to commit directly here if you're a maintainer and you're confident that you know the change you want to make. |
Indeed. I was hoping another contributor would be willing to add an API overview - maybe after this merges? I know there's room for further tidying but as Voltaire never quite said, “the perfect is the enemy of the deployed”. |
Agree. We've also highlighted a path to organizing the docs in #24 - this import gives us something real to iterate on. |
A simple contact page, needs more work.
Spelling correction for link title.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
Added spelling correction.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: adambkaplan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@sftim in Monday's call, the community expressed strong desire for keeping documentation closer to the code repositories (ex - github.com/shipwright-io/build), and syncing that content here. Tekton has an interesting script that facilitates this process [1]. @zhangtbj @qu1queee @gabemontero I'd like to propose the following (will also send this to the dev mailing list):
|
+1 @adambkaplan |
We can fetch the content over from https://github.com/shipwright-io/build during a build of this repo, so that this repo doesn't hold a synced copy but it still previews OK locally, on Netlify, and publishes how we expect. BTW what we lose there is CI/CD: how do we ensure that a documentation change to https://github.com/shipwright-io/build is valid? |
I think we can take a near term/long term strategy here Near term: keep a synced copy in git, update via pull requests. My hope is that with the docs GitHub action, we will catch 90% of bugs that would cause the Netlify deployment to fail from synced content. |
+1, thanks! |
/lgtm |
A quick PR to import documentation from https://github.com/shipwright-io/build/tree/master/docs