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

Import documentation #27

Merged
merged 4 commits into from
Mar 24, 2021
Merged

Import documentation #27

merged 4 commits into from
Mar 24, 2021

Conversation

sftim
Copy link
Contributor

@sftim sftim commented Mar 16, 2021

A quick PR to import documentation from https://github.com/shipwright-io/build/tree/master/docs

@sftim
Copy link
Contributor Author

sftim commented Mar 16, 2021

@adambkaplan thoughts?

@sftim
Copy link
Contributor Author

sftim commented Mar 16, 2021

/kind documentation

@openshift-ci-robot openshift-ci-robot added the kind/documentation Categorizes issue or PR as related to documentation. label Mar 16, 2021
@zhangtbj
Copy link
Contributor

Can we just link the document from shipwright/build directly instead copy and store a copy in the website repo?

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.)

@adambkaplan
Copy link
Member

Can we just link the document from shipwright/build directly instead copy and store a copy in the website repo?

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/

Copy link
Member

@adambkaplan adambkaplan left a 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:

  1. "Concepts"
  2. "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"
Copy link
Member

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.

content/en/docs/api/build.md Show resolved Hide resolved
@@ -0,0 +1,170 @@
---
title: Authentication during builds
Copy link
Member

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"

title: Control flow
---

The following image illustrate the interactions between the Build, BuildRun controller and the Tekton Pipeline controller:
Copy link
Member

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

Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

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"
Copy link
Member

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

@sftim
Copy link
Contributor Author

sftim commented Mar 17, 2021

Can we just link the document from shipwright/build directly instead copy and store a copy in the website repo?

Not super easily. Hugo Markdown and the documentation in shipwright/build are a different format.

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 shipwright/build touch docs, and fail the CI test if the Netlify preview build fails. I can build that for you but it's loads more effort than moving a few Markdown files to a different repo.

@sftim
Copy link
Contributor Author

sftim commented Mar 17, 2021

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.

@sftim
Copy link
Contributor Author

sftim commented Mar 17, 2021

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?

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”.

@adambkaplan
Copy link
Member

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.

@openshift-ci-robot openshift-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 17, 2021
@openshift-ci-robot openshift-ci-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 17, 2021
Spelling correction for link title.
Copy link
Member

@adambkaplan adambkaplan left a 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.

content/en/docs/api/build.md Show resolved Hide resolved
@openshift-ci-robot
Copy link

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 18, 2021
@adambkaplan
Copy link
Member

@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. Merge this PR so we have a base level of content to work with.
  2. Update the folder structure and file front matter in website so the docs are structured and presented to our liking.
  3. Add the appropriate front matter to the docs in build
  4. Incorporate the Tekton sync script (with adjustments as needed) into website.

[1] https://github.com/tektoncd/website/tree/main/sync

@gabemontero
Copy link
Member

+1 @adambkaplan

@sftim
Copy link
Contributor Author

sftim commented Mar 23, 2021

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?
We don't have that now so there's no regression.

@adambkaplan
Copy link
Member

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?
We don't have that now so there's no regression.

I think we can take a near term/long term strategy here

Near term: keep a synced copy in git, update via pull requests.
Medium term: Add a "docs" GitHub action in shipwright-io/build (and future repositories) which checks out the website code, runs the sync, and then has hugo generate the static content. Failures here will need to have clear messaging so contributors know what went wrong and how to fix it.
Long term: Stop syncing content to git, switch to nightly deployments.

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.

@zhangtbj
Copy link
Contributor

+1, thanks!

@adambkaplan
Copy link
Member

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Mar 24, 2021
@openshift-merge-robot openshift-merge-robot merged commit ff879c1 into shipwright-io:master Mar 24, 2021
@sftim sftim deleted the 20210316_initial_docs branch March 24, 2021 16:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. kind/documentation Categorizes issue or PR as related to documentation. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants