Add an example how to run services as an oc plugin, fix for user.Name and user.Email (#84)

* Add plugin docs, Dockerfile and script
* Set git config user and email 
* readme fix

Author: a-roberts

README.md

@@ -21,9 +21,6 @@ $ export GITHUB_TOKEN=<paste in GitHub access token>
 $ ./services promote --from https://github.com/organisation/first-environment.git --to https://github.com/organisation/second-environment.git --service service-a --commit-name <User to commit as> --commit-email <Email to commit as>
 ```
 
-If the `commit-name` and `commit-email` are not provided, it will attempt to find them in `~/.gitconfig`, otherwise it will fail.
-
-
 This will _copy_ all files under `/services/service-a/base/config/*` in `first-environment` to `second-environment`, commit and push, and open a PR for the change.
 
 
@@ -87,3 +84,13 @@ See the [tekton-example](./tekton-example/README.md) directory for more on using
 ## Release process
 
 When a new tag is pushed with the `v` prefix, a GitHub release will be created with binaries produced for 64-bit Linux, and Mac automatically.
+
+## Experimental plugin section
+
+Inside of the `plugin` folder you'll see documentation and other files related to using the `services` binary as a plugin to `oc`. This has been tested with the following version on OpenShift 4.3:
+
+```
+Client Version: openshift-clients-4.3.13-202004121622
+Server Version: 4.3.13
+Kubernetes Version: v1.16.2
+```

automerge-example/README.md

@@ -18,13 +18,6 @@ This example is for more advanced users. Start with the [tekton-example](../tekt
 
 Our samples currently work with GitHub. They use the `hub` CLI to create a merge commit that when pushed, will merge the associated Pull Request. See [here](https://hub.github.com/hub-merge.1.html) for more details.
 
-## gitconfig
-
-Since we are creating git commits within the Tekton tasks, we need to know the username and email address to associate with them, as in our ['tekton-example'](../tekton-example/README.md). So, edit `gitconfig` and
-
-```sh
-kubectl create configmap promoteconfigmap --from-file=gitconfig
-```
 
 ## Dockerfile
 
@@ -86,7 +79,7 @@ Set up your Service Account and Secret as per the guide above. In this case you
 - A ServiceAccount configured for use by Tekton.
 - A Tekton-compatible Secret patched onto that that ServiceAccount containing your GitHub token.
 
-This secret is used in two related ways. We check the source repository out using a Tekton Git PipelineResource. This sets up `~/.gitconfig` with the credentials needed for `git push` to work. It gets these credentials from the `accessToken` field of the relevant secret patched onto the ServiceAccount running the Tekton Task. We then extract the same field and export it into the `GITHUB_TOKEN` environment variable to make `hub merge` work. Instructions for creating this secret are in the Getting Started document linked above. You should have resources of the form, 
+This secret is used in two related ways. We check the source repository out using a Tekton Git PipelineResource. This sets up Git with the credentials needed for `git push` to work. It gets these credentials from the `accessToken` field of the relevant secret patched onto the ServiceAccount running the Tekton Task. We then extract the same field and export it into the `GITHUB_TOKEN` environment variable to make `hub merge` work. Instructions for creating this secret are in the Getting Started document linked above. You should have resources of the form, 
 
 ```yaml
 ---

automerge-example/standalone/templates/automerge-task.yaml

@@ -4,19 +4,15 @@ metadata:
   name: automerge-task
 spec:
   params:
-  - name: github-config
+  - name: commit-name
     type: string
-    description: configmap name of the gitconfig file that has user name, user e-mail.  The key name is gitconfig. It can be created by "kubectl create configmap <configmap name> --from-file=gitconfig"
+    description: GitHub name to author the commit with
+  - name: commit-email
+    type: string
+    description: GitHub email to author the commit with
   - name: github-secret
     type: string
     description: Name of the secret containing an access token for Github. Expects Tekton format, 'username' and 'password' keys.
-  volumes:
-  - name: gitconfig
-    configMap:
-      name: $(params.github-config)
-      items:
-        - key: gitconfig
-          path: gitconfig
   inputs:
     resources:
       - name: git-source
@@ -31,13 +27,8 @@ spec:
       kubectl apply -k git-source/environments/dev/env --dry-run=client
   - name: merge-pr
     image: YOUR_DOCKER_HUB_ID/hub-test
-    volumeMounts:
-    - name: gitconfig
-      mountPath: /root
     script: |
       #!/bin/bash -x
-
-      cat /root/gitconfig >> $HOME/.gitconfig
       fullPRLink=$(yq r pull-request/pr.json 'Link')
       prURL=${fullPRLink%.diff}
 

automerge-example/webhooks/templates/automerge-task.yaml

@@ -4,10 +4,7 @@ metadata:
   name: automerge-task
 spec:
   params:
-  - name: github-config
-    type: string
-    description: configmap name of the gitconfig file that has user name, user e-mail.  The key name is gitconfig. It can be created by "kubectl create configmap <configmap name> --from-file=gitconfig"
-  - name: github-secret
+ - name: github-secret
     type: string
     description: Name of the secret containing an access token for Github. Expects Tekton format, 'username' and 'password' keys.
   - name: event-type
@@ -19,13 +16,6 @@ spec:
   - name: pull-request-url
     type: string
     description: The URL of the pull request, where applicable
-  volumes:
-  - name: gitconfig
-    configMap:
-      name: $(params.github-config)
-      items:
-        - key: gitconfig
-          path: gitconfig
   inputs:
     resources:
       - name: git-source
@@ -38,9 +28,6 @@ spec:
       kubectl apply -k git-source/env --dry-run=client
   - name: merge-pr
     image: YOUR_DOCKER_HUB_ID/hub-test
-    volumeMounts:
-    - name: gitconfig
-      mountPath: /root
     script: |
       #!/bin/bash -x
 
@@ -52,12 +39,11 @@ spec:
           echo "do nothing"
         fi
       elif [ $(params.event-type) = "pull_request" ]; then
-      
-        cat /root/gitconfig >> $HOME/.gitconfig
         # GHE requires some extra config
         # Replace `YOUR_GHE` with your GitHub Enterprise domain e.g. `github.ibm.com`
         git config --global --add hub.host YOUR_GHE
-
+        git config --global user.name $(params.commit-name)
+        git config --global user.email $(params.commit-email)
         cd git-source
         export HUB_VERBOSE=true
         hub merge $(params.pull-request-url)

pkg/git/mock/mock.go

@@ -203,7 +203,6 @@ func (m *Repository) AssertBranchNotCreated(t *testing.T, from, name string) {
 // AssertFileCopiedInBranch asserts the filename was copied from and to in a
 // branch.
 func (m *Repository) AssertFileCopiedInBranch(t *testing.T, branch, from, name string) {
-	fmt.Printf("copied: %s\n", m.copiedFiles)
 	if !hasString(key(branch, from, name), m.copiedFiles) {
 		t.Fatalf("file %s was not copied from %s to branch %s", name, from, branch)
 	}

pkg/git/repository.go

@@ -158,9 +158,30 @@ func (r *Repository) StageFiles(filenames ...string) error {
 }
 
 // Commit does the git commit -m with the msg & author
+// after first running git config commands for the user.name and user.email
+// these are intentionally *not* global settings because we don't want to touch a user's $HOME/.gitconfig
+// This means the settings only apply inside of our local repository cache.
 func (r *Repository) Commit(msg string, author *Author) error {
+	_, err := r.execGit(r.repoPath(), envFromAuthor(author), "status")
+	if err != nil {
+		return fmt.Errorf("could not set name, err: %w", err)
+	}
+
+	command := fmt.Sprintf("config user.name \"%s\"", author.Name)
+	commandAsArgs := strings.Split(command, " ")
+	_, err = r.execGit(r.repoPath(), envFromAuthor(author), commandAsArgs...)
+	if err != nil {
+		return fmt.Errorf("could not set name, err: %w", err)
+	}
+	command = fmt.Sprintf("config user.email \"%s\"", author.Email)
+	commandAsArgs = strings.Split(command, " ")
+	_, err = r.execGit(r.repoPath(), envFromAuthor(author), commandAsArgs...)
+	if err != nil {
+		return fmt.Errorf("could not set email, err: %w", err)
+	}
+
 	args := []string{"commit", "-m", msg}
-	_, err := r.execGit(r.repoPath(), envFromAuthor(author), args...)
+	_, err = r.execGit(r.repoPath(), envFromAuthor(author), args...)
 	return err
 }
 
@@ -214,6 +235,7 @@ func envFromAuthor(a *Author) []string {
 	sf := func(k, v string) string {
 		return fmt.Sprintf("%s=%s", k, v)
 	}
+
 	return []string{
 		sf("GIT_AUTHOR_NAME", a.Name),
 		sf("GIT_AUTHOR_EMAIL", a.Email)}

plugin/Dockerfile

@@ -0,0 +1,26 @@
+FROM ubuntu AS oc-base
+
+# Install curl
+RUN apt-get update 
+RUN apt-get install -y curl
+
+# Install oc
+RUN curl -O https://mirror.openshift.com/pub/openshift-v4/clients/oc/4.3/linux/oc.tar.gz
+
+RUN tar xvf oc.tar.gz
+RUN chmod +x ./oc
+RUN cp ./oc /usr/local/bin/
+
+# Build services binary, rename and add to path
+FROM golang:latest AS build
+COPY . /go/build
+WORKDIR /go/build
+
+RUN CGO_ENABLED=0 GOOS=linux go build ./cmd/services
+
+FROM registry.access.redhat.com/ubi8/ubi-minimal
+RUN microdnf install git
+WORKDIR /root/
+COPY --from=build /go/build/services /usr/local/bin/oc-services
+COPY --from=oc-base /usr/local/bin/oc /usr/local/bin/
+ENTRYPOINT ["/usr/local/bin/oc"]

plugin/README.md

@@ -0,0 +1,13 @@
+This folder contains an example script that will compile the services binary and name it in such a way that it can be used as a plugin to `oc` - using `oc services promote ...` for example.
+
+A Dockerfile is also provided that will pull in `oc` and copy the built plugin binary into that image. You could then push that image to your own testing place on Dockerhub for use later - be it as a standalone container or as part of a Tekton Task.
+
+Build it with the following command from the main `services` folder:
+
+`docker build -f plugin/Dockerfile -t <dockerusername>/oc-services-plugin-experiment .` 
+
+You can then do
+
+`docker run -e GITHUB_TOKEN=<mytoken> <dockerusername>/oc-services-plugin-experiment:latest services promote --from https://github.com/myorg/myrepo --to https://github.com/myorg/myotherrepo --service myservicename --commit-name=<mygitname> --commmit-email=<mygitemail>`
+
+and that's using `promote` but from being an `oc plugin` - useful for seeing if anything breaks.

plugin/make-plugin.sh

@@ -0,0 +1,7 @@
+#!/bin/bash -ex
+
+go build ./cmd/services
+mv ./services ./oc-services
+chmod +x ./oc-services
+sudo mv ./oc-services /usr/local/bin/
+oc services --help

tekton-example/README.md

@@ -14,7 +14,6 @@ Creation of a TaskRun (using `promote-run.yaml`) will then further promote from
 - `service-promote-pipeline.yaml`: Creates a pipeline that executes `build-task.yaml` and `service-promote.yaml`
 - `promote.yaml`: Creates a pull request from one repository to another repository
 - `build-task.yaml`: This task builds a git source into a docker image and pushes to a docker registry
-- `gitconfig`: Data file for the configmap - includes a GitHub user ID and email address
 
 ## Pre-requisites
 
@@ -47,23 +46,19 @@ kubectl apply -f resources
 ```shell 
 kubectl apply -f templates
 ```
-- Edit `gitconfig` to contain your GitHub username and email address
-
-- Create a configmap:
-```shell
-kubectl create configmap promote-configmap --from-file=gitconfig
-```
-This will store your GitHub username and email address in key-value pairs that can be used in the PipelineRun. 
 
 ## Execute Pipeline
 
 The PipelineRun you will create is designed to build your microservice from its development repository and then promote the new configuration to a GitOps repository (representing a different environment, for example development, staging, test or production).
 
 - To create the PipelineRun, use:
 ```shell
-tkn pipeline start service-promote-pipeline --resource git-source=git-app-repo --resource docker-image=docker-app-image--param commitID=v1 --param github-secret=promote-secret --param github-config=promote-configmap --param to=https://github.com/<github username>/<github repo>.git --workspace name=repo-space,claimName=repopvc,subPath=dir -s demo --showlog
+tkn pipeline start service-promote-pipeline --resource git-source=git-app-repo --resource docker-image=docker-app-image--param commitId=v1 --param github-secret=promote-secret --param commit-name=<yourgitname> --param commit-email=<yourgitemail> --param to=https://github.com/<github username>/<github repo>.git --param service=promote-demo --workspace name=repo-space,claimName=repopvc,subPath=dir -s demo --showlog
 ```
 
+This example promotes from the `promote-demo` repository, containing a service with the same name.
+
+
 - This creates a PipelineRun that executes the `service-promote-pipeline`, which will build the code and promote it to a repository you have specified
 - The logs will be outputted to your console, and you can also view its progress in the Tekton Dashboard.
 
@@ -72,9 +67,9 @@ tkn pipeline start service-promote-pipeline --resource git-source=git-app-repo -
 Optionally, you can run a subsequent promote from one GitOps repository to another (e.g staging to prod) after merging the pull request on your first GitOps repository. For this you will need a third repository, and for this you can fork: https://github.com/rhd-gitops-example/gitops-example-staging
 
 -  To do this second promote, you will need to create a TaskRun that executes a task promoting from a testing repository to a production repository
-- To create the TaskRun, use:
+- To create the TaskRun (again this uses a service called `promote-demo`), use:
 ```shell
-tkn task start promote --param github-secret=promote-secret--param from=https://github.com/<github username>/<github repo> --param from=https://github.com/<github username>/<github repo>.git --param github-config=promote-configmap --param service=service-a -s demo --showlog
+tkn task start promote --param github-secret=promote-secret --param from=https://github.com/<yourorg>/<yourdevrepo>.git --param to=https://github.com/<yourorg>/<yourstagingrepo>.git --param commit-name=<yourgitname> --param commit-email=<yourgitemail> --param service=promote-demo -s demo --showlog
 ```
 This will start the TaskRun and output its logs, and you can also view its progress in the Tekton Dashboard.