Generate adoc copies in /content/en/docs to shipwright-io#78

Gemfile.lock

@@ -8,6 +8,3 @@ PLATFORMS
 
 DEPENDENCIES
   asciidoctor (~> 2.0, >= 2.0.17)
-
-BUNDLED WITH
-   2.3.7

content/en/docs/_index.md → content/en/docs/_index.adoc

@@ -9,54 +9,55 @@ menu:
     weight: 20
 ---
 
-
-
 Shipwright is an extensible framework for building container images on Kubernetes.
 
 Shipwright supports popular tools such as Kaniko, Cloud Native Buildpacks, Buildah, and more!
 
-Shipwright is based around four elements for each build:
+In Shipwright, each build is on the following elements:
 
-1. Source code - the "what" you are trying to build
-1. Output image - "where" you are trying to deliver your application
-1. Build strategy - "how" your application is assembled
-1. Invocation - "when" you want to build your application
+* Source code - the "what" you are trying to build
+* Output image - "where" you are trying to deliver your application
+* Build strategy - "how" your application is assembled
+* Invocation - "when" you want to build your application
 
-## Comparison with local image builds
+== Comparison with local image builds
 
 Developers who use Docker are familiar with this process:
 
-1. Clone source from a git-based repository ("what")
-2. Build the container image ("when" and "how")
-
-  ```bash
+. Clone source from a git-based repository ("what")
+. Build the container image ("when" and "how")
++
+[,bash]
+----
   docker build -t registry.mycompany.com/myorg/myapp:latest .
-  ```
-
-3. Push the container image to your registry ("where")
+----
 
-  ```bash
+. Push the container image to your registry ("where")
++
+[,bash]
+----
   docker push registry.mycompany.com/myorg/myapp:latest
-  ```
+----
 
-## Shipwright Build APIs
+== Shipwright Build APIs
 
 Shipwright's Build API consists of four core
-[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions)
+https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#customresourcedefinitions[CustomResourceDefinitions]
 (CRDs):
 
-1. [`Build`](/docs/api/build/) - defines what to build, and where the application should be delivered.
-1. [`BuildStrategy` and `ClusterBuildStrategy`](/docs/api/buildstrategies/) - defines how to build an application for an image
-   building tool.
-1. [`BuildRun`](/docs/api/buildrun/) - invokes the build.
-   You create a `BuildRun` to tell Shipwright to start building your application.
+* link:/docs/api/build/[`Build`] - defines what to build, and where the application should be delivered.
+* link:/docs/api/buildstrategies/[`BuildStrategy` and `ClusterBuildStrategy`] - defines how to build an application for an image
+building tool.
+* link:/docs/api/buildrun/[`BuildRun`] - invokes the build.
+You create a `BuildRun` to tell Shipwright to start building your application.
 
-### Build
+=== Build
 
 The `Build` object provides a playbook on how to assemble your specific application. The simplest
 build consists of a git source, a build strategy, and an output image:
 
-```yaml
+[,yaml]
+----
 apiVersion: build.dev/v1alpha1
 kind: Build
 metadata:
@@ -71,11 +72,11 @@ spec:
     kind: ClusterBuildStrategy
   output:
     image: registry.mycompany.com/my-org/taxi-app:latest
-```
+----
 
 Builds can be extended to push to private registries, use a different Dockerfile, and more.
 
-### BuildStrategy and ClusterBuildStrategy
+=== BuildStrategy and ClusterBuildStrategy
 
 `BuildStrategy` and `ClusterBuildStrategy` are related APIs to define how a given tool should be
 used to assemble an application. They are distinguished by their scope - `BuildStrategy` objects
@@ -85,7 +86,8 @@ The spec of a `BuildStrategy` or `ClusterBuildStrategy` consists of a `buildStep
 specifications. Below is an example spec for Kaniko, which can build an image from a
 Dockerfile within a container:
 
-```yaml
+[,yaml]
+----
 # this is a fragment of a manifest
 spec:
   buildSteps:
@@ -121,17 +123,17 @@ spec:
         requests:
           cpu: 250m
           memory: 65Mi
-```
+----
 
-### BuildRun
+=== BuildRun
 
 Each `BuildRun` object invokes a build on your cluster. You can think of these as a Kubernetes
 `Jobs` or Tekton `TaskRuns` - they represent a workload on your cluster, ultimately resulting in a
-running `Pod`. See [`BuildRun`](/docs/api/buildrun/) for more details.
+running `Pod`. See link:/docs/api/buildrun/[`BuildRun`] for more details.
 
-## Further reading
+== Further reading
 
-- [Configuration](/docs/configuration/)
-- Build controller observability
-  - [Metrics](/docs/metrics/)
-  - [Profiling](/docs/profiling/)
+* link:/docs/configuration/[Configuration]
+* Build controller observability
+ ** link:/docs/metrics/[Metrics]
+ ** link:/docs/profiling/[Profiling]