- Setting up development environment
- Project structure
- Deploying the Operator
This developer guide aims to walk a new developer on how to setup up their environment to be able to contribute to this project.
To setup your system for development of the operator, follow the steps below:
Install golang in your environment.
operator-sdkreleases can be found in the projects repository.
To check your version of operator SDK run,
To contribute code to the current GitLab Operator release, you will need at least operator SDK v1.0.0.
gitlab-operatorrepository into your GOPATH.
git clone firstname.lastname@example.org:gitlab-org/cloud-native/gitlab-operator.git
The GitLab Operator is built using the Operator SDK v1.0.0 and consequently uses the Kubebuilder v2 layout format. This is necessary to know since there was a change in project directory and some of the tooling used by operator SDK.
$ pwd gitlab-operator $ tree -dL 2 . . ├── api │ └── v1beta1 ├── bundle │ ├── manifests │ ├── metadata │ └── tests ├── config │ ├── certmanager │ ├── crd │ ├── default │ ├── deploy │ ├── manager │ ├── manifests │ ├── prometheus │ ├── rbac │ ├── samples │ ├── scorecard | ├── test │ └── webhook ├── controllers │ ├── backup │ ├── gitlab │ ├── helpers │ ├── runner │ ├── settings │ ├── testdata │ └── utils ├── doc ├── hack │ └── assets ├── helm │ └── testdata └── scripts └── manifests
controllersdirectory contains the controller implementations for the GitLab and GitLab Backup controllers.
apidirectory contains the API resource definitions for the GitLab and GLBackup resources owned by the operator. The API definitions are grouped by their API version. The
api/<api_version>contains spec definitions and markers used to generate the Custom Resource Definitions and Cluster Service Version file used by OLM.
config/samplesdirectory contains an example manifest for the GitLab Custom Resource.
config/testdirectory contains a parametrized GitLab definition used for running integration tests.
An example is shown below:
The contents of
config/rbac/customwere created manually and is not affected by the RBAC markers.
Most of the other contents of the config directory are automatically generated but could be modified using
hack/assetspath contains resources that would need to be pushed inside the operator image when the container image is being built. This is where release files would go.
Makefile allows us to customize manage different tasks such as:
Creating an Operator Lifecycle Manager bundle
Building a container image for the operator
make docker-build IMG=quay.io/<username>/gitlab-operator:latest
Pushing the image to a container registry
make docker-push IMG=quay.io/<username>/gitlab-operator:latest
Run the operator locally to test changes
For instructions on deploying the operator, see the installation docs.
There have been a couple of functions added to
to assist in the development of features and the writing of tests.
dumpTemplate() function will take the template object from the GitLab
adapter and return the rendered YAML of the Helm chart as a string. Since
the Go test framework will absorb anything written to stdout, the
dumpTemplateToFile() will write the YAML to a file for inspection. It
is important to note that if just a filename is provided that the file will
be written to the subdirectory where the test file resides rather than the
directory where the tests were initiated from. An absolute file path is
necessary if one desires the file to be written where the tests are
dumpHelmValues() will return the YAML representation of the
Helm values as string. This is can be used to verify that the intended
values are set at the beginning of any tests. The
is used to write the YAML to a file for inspection and the filename argument
has the same limitations as