Removed LR specific files and amends, add Dockerfile.test and updated the README

Author: mariogiuffrida

.github/CODEOWNERS

@@ -63,6 +63,7 @@ anaconda-mode/
 *.dylib
 # Test binary, build with 'go test -c'
 *.test
+!Dockerfile.test
 # Output of the go coverage tool, specifically when used with LiteIDE
 *.out
 ### Vim ###

.github/workflows/sync.yml

@@ -0,0 +1,25 @@
+# Build the manager binary
+FROM golang:1.16 as tester
+
+ENV version 1.0.8
+ENV arch amd64
+
+# Copy everything in the go src
+WORKDIR /go/src/cdap.io/cdap-operator
+COPY ./ ./
+
+# Install Kubebuilder
+RUN curl -L -O "https://github.com/kubernetes-sigs/kubebuilder/releases/download/v${version}/kubebuilder_${version}_linux_${arch}.tar.gz" && \
+    tar -zxvf kubebuilder_${version}_linux_${arch}.tar.gz && \
+    mv kubebuilder_${version}_linux_${arch} /usr/local/kubebuilder && \
+    cp /usr/local/kubebuilder/bin/* /usr/local/bin
+
+# Install setup-envtest
+RUN go install sigs.k8s.io/controller-runtime/tools/setup-envtest@latest
+
+# download envtest 1.19.x for kubebuilder and to set KUBEBUILDER_ASSETS environment variable
+RUN $(go env GOPATH)/bin/setup-envtest use -p env 1.19.x > /tmp/setup_envtest.sh && \
+    eval `$(go env GOPATH)/bin/setup-envtest use -p env 1.19.x` && \
+    rm /tmp/setup_envtest.sh
+
+CMD make test

.gitignore

@@ -2,7 +2,7 @@
 # Image URL to use all building/pushing image targets
 IMG ?= controller:latest
 # Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
-CRD_OPTIONS ?= "crd:trivialVersions=true,maxDescLen=0"
+CRD_OPTIONS ?= "crd:trivialVersions=true"
 
 # Get the currently used golang install path (in GOPATH/bin, unless GOBIN is set)
 ifeq (,$(shell go env GOBIN))

Dockerfile.test

@@ -12,44 +12,9 @@ The CDAP Operator is still under active development and has not been extensively
 
 ## Quick Start
 
-### Repository Setup
-
-The core of this codebase has contributors both in `LiveRamp` and `cdapio` Github organisations so we have customised the Git setup to enable LiveRamp devs to pull request against an internal production branch called `lr-main` whereas `develop` tracks an upstream branch, namely `cdapio/cdap-operator/tree/develop`. This is enabled through a Github action that runs sync upstream tags and the `remote` branch every night. 
-
-### Local Git Setup
-
-Given the repository setup we reccomend the following local git setup: 
-
-```
-origin	git@github.com:LiveRamp/cdap-operator.git (fetch)
-origin	git@github.com:LiveRamp/cdap-operator.git (push)
-upstream	https://github.com/cdapio/cdap-operator (fetch)
-upstream	DISABLE (push)
-```
-
-This enables a developer to develop and PR against the LiveRamp "fork" as the `origin` while the `upstream` managed by the Google CDAP team can be pulled in at any time as well. Although not strictly necessary the following can be achieved by cloning this repo and then running
-
-`git remote add upstream https://github.com/cdapio/cdap-operator.git`
-
-`git fetch upstream`
-
-`git remote --push upstream no-pushing`
-
-### CI
-
-Automated CI for this project runs for PR and Branch commits against `lr-main` as the base branch. CI is enabled through Google Cloud Build. Images are currently pushed to `eu.gcr.io/liveramp-eng-data-ops-dev/cdap-controller` , a container registry managed by the DataOps team. Builds off of `lr-main` are pushed with a `latest` tag whereas builds from PRs are pushed with tag `{pr_number}`. It is reccomended for production deploys a purpose built tag be used. Please see `cloudbuild.yaml` and the [cloud build triggers](https://console.cloud.google.com/cloud-build/triggers?project=liveramp-eng-data-ops-dev) config for more details on the build configuration.
-
-### CD
-
-CD for this repo is managed seperately through the `LiveRamp/dop-infra` repository. This is so that we can have both the `cdap-operator` and `cdap` deployments managed through a single helm configuration. They are usually deployed in conjunction. 
-
-In the future we may look to change the CI process to use a LiveRamp build tool like Jenkins but at the moment this does not add any additional value for us as the `cdap-operator` codebase does not depend on any LiveRamp artifacts.
-
-For any PR against `lr-main` you may manually trigger a one off build by typing `/gcbrun` as a comment.
-
 ### Build and Run Locally
 
-You can checkout the CDAP Operator source code, build and run locally. To build the CDAP Operator, you need to setup your environment for the [Go](https://golang.org/doc/install) language. Also, you should have a Kubernetes cluster running and accessible in your current `kubectl` context. This could be either a Kubernetes cluster hosted on a cloud platform like GCP GKE or on a local Minikube instance.
+You can checkout the CDAP Operator source code, build and run locally. To build the CDAP Operator, you need to setup your environment for the [Go](https://golang.org/doc/install) language. Also, you should have a Kubernetes cluster 
 
 1. Checkout CDAP Operator source
    ```
@@ -75,7 +40,7 @@ You can checkout the CDAP Operator source code, build and run locally. To build
    kubectl apply -f config/samples/cdap_v1alpha1_cdapmaster.yaml
    ```
 
-### Build Controller Docker Image and Deploy in Kubernetes Manually
+### Build Controller Docker Image and Deploy in Kubernetes
 
 You can also build a docker image containing the CDAP controller and deploy it to Kubernetes.
 
@@ -117,3 +82,14 @@ rm /tmp/setup_envtest.sh
 ```
 
 4. Run `make test`
+
+#### Running Unit Tests in a docker image
+
+From the project root folder build the test image by running the following
+```
+docker build -f Dockerfile.test . -t test
+```
+Execute the image with
+```
+docker run test
+```

Makefile

@@ -4,5 +4,5 @@ apiVersion: kustomize.config.k8s.io/v1beta1
 kind: Kustomization
 images:
 - name: controller
-  newName: http://eu.gcr.io/liveramp-eng-data-ops-dev/cdap-controller
-  newTag: 2.1.0
+  newName: controller
+  newTag: latest