You must have a working Go environment and then clone the repo:
mkdir -p $GOPATH/src/sigs.k8s.io
cd $GOPATH/src/sigs.k8s.io
git clone https://github.com/kubernetes-sigs/service-apis
cd service-apis
This project works with Go modules; you can chose to setup your environment outside $GOPATH as well.
You will need to have Docker installed to perform the steps below.
We are using the Github issues and project dashboard to manage the list of TODOs for this project:
Issues labeled good first issue
and help wanted
are especially good for a
first contribution.
We use milestones to track our progress towards releases. Looking at our current milestone can help identify our highest priority issues.
The project uses make
to drive the build.
make
will run code generators, and run static analysis against the code and
generate Kubernetes CRDs.
You can kick off an overall build from the top-level makefile:
make
To install service-apis CRDs into a Kubernetes cluster:
make install
To uninstall CRDs and associated resources:
make uninstall
Service APIs follows a similar pull request process as Kubernetes. Merging a pull request requires the following steps to be completed before the pull request will be merged automatically.
- Sign the CLA (prerequisite)
- Open a pull request
- Pass verification tests
- Get all necessary approvals from reviewers and code owners
Make sure you run the static analysis over the repo before submitting your changes. The Prow presubmit will not let your change merge if verification fails.
make verify
The site documentation is written in mkdocs format. The files are
contained in docs-src/
. Generated files are in docs/
and published to
Github Pages.
Building the docs:
make docs
Live preview for editing (view on http://localhost:8000, CTRL-C to quit):
make serve
Remove generated documentation files:
make clean
The docs are published automatically to Github pages. When making changes to the
documentation, generate the new documentation and make the generated code a
self-contained commit (e.g. the changes to docs/
). This will keep the code
reviews simple and clearly delineate user vs generated content.