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.

Sign up for GitHub

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

Jump to bottom

Fix broken build links #99

Merged
merged 1 commit into from
Aug 21, 2023
Merged

Fix broken build links #99

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion content/en/blog/posts/2021-08-02-adding-gatekeeper.md/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ resources:
---


[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a customizable [admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) for Kubernetes, which allows you to configure [policy](https://www.openpolicyagent.org/docs/latest/policy-language/) over what resources can be created in the cluster. In particular, we can use Gatekeeper to add policy to Shipwright [`Build`](/docs/api/build/)s. In this example, you can see how you can use a policy to control what source repositories Shipwright is allowed to build, so that you can have more control over what code executes inside your cluster.
[Gatekeeper](https://github.com/open-policy-agent/gatekeeper) is a customizable [admission webhook](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks) for Kubernetes, which allows you to configure [policy](https://www.openpolicyagent.org/docs/latest/policy-language/) over what resources can be created in the cluster. In particular, we can use Gatekeeper to add policy to Shipwright [`Build`](/docs/build/)s. In this example, you can see how you can use a policy to control what source repositories Shipwright is allowed to build, so that you can have more control over what code executes inside your cluster.

[![Gatekeeper](opa.png)](https://github.com/securekubernetes/securekubernetes/blob/master/docs/img/opa.png)

Expand Down
8 changes: 4 additions & 4 deletions content/en/docs/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,10 +45,10 @@ Shipwright's Build API consists of four core
[CustomResourceDefinitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#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
1. [`Build`](/docs/build/) - defines what to build, and where the application should be delivered.
1. [`BuildStrategy` and `ClusterBuildStrategy`](/docs/build/buildstrategies/) - defines how to build an application for an image
building tool.
1. [`BuildRun`](/docs/api/buildrun/) - invokes the build.
1. [`BuildRun`](/docs/build/buildrun/) - invokes the build.
You create a `BuildRun` to tell Shipwright to start building your application.

### Build
Expand Down Expand Up @@ -127,7 +127,7 @@ spec:

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 [`BuildRun`](/docs/build/buildrun/) for more details.

## Further reading

Expand Down