Add unit tests to CI (#288)

.github/workflows/release.yml → .github/workflows/Merge.yml

@@ -1,21 +1,22 @@
-name: Release
+name: Merge
 
 on:
- release:
- types: [prereleased]
+ push:
+ branches:
+ - master
 
 jobs:
+ vet:
+ uses: ./.github/workflows/vet.yml
+ unit-test:
+ uses: ./.github/workflows/unit.yml
  build:
  uses: ./.github/workflows/build.yml
  e2e:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, vet, unit-test]
  uses: ./.github/workflows/e2e.yml
  integration:
- uses: ./.github/workflows/integration.yml
- publish:
  if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
- needs: [build, e2e, integration]
- uses: ./.github/workflows/publish.yml
- docs:
- if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
- needs: [build, e2e, integration]
- uses: ./.github/workflows/docs.yml
+ needs: [build, vet, unit-test]
+ uses: ./.github/workflows/integration.yml

.github/workflows/PR.yml

@@ -0,0 +1,25 @@
+name: PR
+
+on:
+ pull_request:
+ types: ['opened', 'reopened', 'synchronize']
+ branches: [ "master" ]
+ paths:
+ - '**' # all files otherwise excludes wont work
+ - '!**/**/*.md' # ignore markdown files
+
+jobs:
+ vet:
+ uses: ./.github/workflows/vet.yml
+ unit-test:
+ uses: ./.github/workflows/unit.yml
+ build:
+ uses: ./.github/workflows/build.yml
+ e2e:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, vet, unit-test]
+ uses: ./.github/workflows/e2e.yml
+ integration:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, vet, unit-test]
+ uses: ./.github/workflows/integration.yml

.github/workflows/README.md

@@ -0,0 +1,15 @@
+# Workflows
+
+There are two types of workflows in this directory. I would put them in subfolders but GitHub Actioins don't support that. Since we can't use folders, capital letters are used for the "Caller" workflows and lowercase for the "Job" workflows. This is just a convention to help keep track of what is what.
+
+## Callers
+
+These are the high level workflows that can be associated with what triggers them. PRs, releases, nightlys, merges, etc. These are made up of jobs that are defined the the other workflows. These are the workflows that you will see in the Actions tab of the repo. By grouping these tasks into parent workflows, the jobs are grouped under one action in the actions tab. They share the smaller 'job' workflows so that they always run the same way.
+
+## Jobs
+
+These are the smaller individual tasks that are used to build up the larger parent workflows. They can be thought of as running unit tests, building the binaries, or linting the code. When you open one of the parent caller actions in the actions tab, they will show these individual jobs.
+
+# Working with workflows
+
+The easiest way to test a workflow is by creating it on your forked repo. This way you have control over the settings and you can manipulate branches anyway you need to trigger the workflow. When testing this way, you should be careful that you are pushing to your repo and not the company's and also make sure to clean everything up in your repo once you have finished testing.

.github/workflows/Release.yml

@@ -0,0 +1,29 @@
+name: Release
+
+on:
+ release:
+ types: [prereleased]
+
+jobs:
+ vet:
+ uses: ./.github/workflows/vet.yml
+ unit-test:
+ uses: ./.github/workflows/unit.yml
+ build:
+ uses: ./.github/workflows/build.yml
+ e2e:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, vet, unit-test]
+ uses: ./.github/workflows/e2e.yml
+ integration:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, vet, unit-test]
+ uses: ./.github/workflows/integration.yml
+ publish:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, e2e, integration, unit-test, vet]
+ uses: ./.github/workflows/publish.yml
+ docs:
+ if: ${{ always() && contains(join(needs.*.result, ','), 'success') }}
+ needs: [build, e2e, integration, unit-test, vet]
+ uses: ./.github/workflows/docs.yml

.github/workflows/build.yml

@@ -1,13 +1,8 @@
 name: Build
 
 on:
- push:
- branches: [ "master" ]
- pull_request:
- branches: [ "master" ]
  workflow_call:
 
-
 jobs:
  linux:
  runs-on: ubuntu-latest

.github/workflows/e2e.yml

@@ -1,10 +1,6 @@
 name: End-to-End Tests
 
 on:
- push:
- branches: [ master ]
- pull_request:
- branches: [ master ]
  workflow_call:
 
 jobs:

.github/workflows/integration.yml

@@ -1,10 +1,6 @@
 name: Integration Tests
 
 on:
- push:
- branches: [ master ]
- pull_request:
- branches: [ master ]
  workflow_call:
 
 jobs:

.github/workflows/unit.yml

@@ -0,0 +1,25 @@
+name: Run Unit Tests
+
+on:
+ workflow_call:
+
+jobs:
+ unit-tests:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v3
+
+ - name: Load environment
+ uses: c-py/action-dotenv-to-setenv@v4
+ with:
+ env-file: .github/.env
+
+ - name: Setup Go ${{ env.GO_VERSION }}
+ uses: actions/setup-go@v4
+ with:
+ go-version: ${{ env.GO_VERSION }}
+
+ - name: Run Unit Tests
+ working-directory: .
+ run: make test

.github/workflows/vet.yml

@@ -0,0 +1,25 @@
+name: Vet Go Code
+
+on:
+ workflow_call:
+
+jobs:
+ vet:
+ runs-on: ubuntu-latest
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v3
+
+ - name: Load environment
+ uses: c-py/action-dotenv-to-setenv@v4
+ with:
+ env-file: .github/.env
+
+ - name: Setup Go ${{ env.GO_VERSION }}
+ uses: actions/setup-go@v4
+ with:
+ go-version: ${{ env.GO_VERSION }}
+
+ - name: Vet Go Code
+ working-directory: .
+ run: go vet

README.md

@@ -1,11 +1,15 @@
-![docker and kubernetes interact](docs/static/images/logo.svg)
+<p align="center">
+ <img src="docs/static/images/logo.svg" alt="docker and kubernetes interact"/>
+</p>
 
 # cri-dockerd
 
 This adapter provides a shim for [Docker Engine](https://docs.docker.com/engine/)
 that lets you control Docker via the
 Kubernetes [Container Runtime Interface](https://github.com/kubernetes/cri-api#readme).
 
+Take a look at the [official docs](https://mirantis.github.io/cri-dockerd/) for more information.
+
 ## IMPORTANT
 
 For users running `0.2.5` or above, the default network plugin is `cni`. Kubernetes 1.24+ has removed `kubenet` and

docs/content/development/unit-tests.md

@@ -0,0 +1,16 @@
+---
+weight: 2
+---
+
+Unit tests can be ran on your local machine without the need for minikube.
+
+## Run the tests
+
+Open a terminal and run the following command:
+
+``` bash
+make test
+```
+
+The tests will run and the results will be printed to the terminal with a summary
+at the end of the test run.