Merge pull request #7 from charlie0129/refactor-crds

Refactor: rename CRs
kubevela · Aug 29, 2022 · 17b2689 · 17b2689
2 parents e8452b8 + f21fb8c
commit 17b2689
Show file tree

Hide file tree

Showing 58 changed files with 1,260 additions and 838 deletions.
diff --git a/.dockerignore b/.dockerignore
@@ -60,3 +60,4 @@ bin
 .github
 docs
 examples
+.git
diff --git a/.github/workflows/docs-check.yaml b/.github/workflows/docs-check.yaml
@@ -15,6 +15,7 @@ on:
 
 jobs:
   checks:
+    name: Check Docs
     runs-on: ubuntu-latest
     steps:
       - name: Install xmllint

diff --git a/.github/workflows/go-checks.yaml b/.github/workflows/go-checks.yaml
@@ -18,6 +18,7 @@ env:
 
 jobs:
   detect-noop:
+    name: Detect No-op Changes
     runs-on: ubuntu-latest
     outputs:
       noop: ${{ steps.noop.outputs.should_skip }}
@@ -32,6 +33,7 @@ jobs:
           concurrent_skipping: false
 
   checks:
+    name: Check Go Code
     runs-on: ubuntu-latest
     needs: detect-noop
     if: needs.detect-noop.outputs.noop != 'true'

diff --git a/.github/workflows/release-binary.yaml b/.github/workflows/release-binary.yaml
@@ -14,7 +14,7 @@ env:
 
 jobs:
   kube-trigger:
-    name: Release kube-trigger binaries
+    name: Release kube-trigger Binaries
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Code
@@ -41,7 +41,7 @@ jobs:
       - name: Get Version
         id: get_version
         run: |
-          export VERSION=$(./make-kt version)
+          VERSION=$(./make-kt version)
           echo ::set-output name=VERSION::${VERSION}
 
       - name: Build Binaries for All Platforms

diff --git a/.github/workflows/release-image.yaml b/.github/workflows/release-image.yaml
@@ -10,7 +10,7 @@ on:
 
 jobs:
   kube-trigger:
-    name: Release kube-trigger image
+    name: Release kube-trigger Images
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Code
@@ -49,7 +49,7 @@ jobs:
         run: ./make-kt all-docker-build-push
 
   manager:
-    name: Release manager image
+    name: Release manager Images
     runs-on: ubuntu-latest
     steps:
       - name: Checkout Code

diff --git a/.github/workflows/unit-test.yaml b/.github/workflows/unit-test.yaml
@@ -19,6 +19,7 @@ env:
 
 jobs:
   detect-noop:
+    name: Detect No-op Changes
     runs-on: ubuntu-latest
     outputs:
       noop: ${{ steps.noop.outputs.should_skip }}
@@ -33,6 +34,7 @@ jobs:
           concurrent_skipping: false
 
   unit-test:
+    name: Run Unit Tests and Integration Tests
     runs-on: ubuntu-latest
     needs: detect-noop
     if: needs.detect-noop.outputs.noop != 'true'

diff --git a/.github/workflows/upload-test-binary.yaml b/.github/workflows/upload-test-binary.yaml
@@ -19,6 +19,7 @@ env:
 
 jobs:
   detect-noop:
+    name: Detect No-op Changes
     runs-on: ubuntu-latest
     outputs:
       noop: ${{ steps.noop.outputs.should_skip }}
@@ -33,9 +34,19 @@ jobs:
           concurrent_skipping: false
 
   upload-test-binary:
+    name: Build and Upload Test Binaries
     needs: detect-noop
     if: needs.detect-noop.outputs.noop != 'true'
     runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        platform:
+          - linux-amd64
+          - darwin-amd64
+          - darwin-arm64
+        binary:
+          - kube-trigger
+          - manager
     steps:
       - name: Checkout Code
         uses: actions/checkout@v3
@@ -64,31 +75,19 @@ jobs:
       - name: Get Version
         id: get_version
         run: |
-          export VERSION=$(./make-kt version)
+          VERSION=$(./make-kt version)
           echo ::set-output name=VERSION::${VERSION}
 
-      - name: Build Binaries for linux and darwin
+      - name: Build Binary
         env:
           DIRTY_BUILD: true
         run: |
-          ./make-kt build-linux_amd64
-          ./make-kt build-darwin_amd64
-          ./make-kt build-darwin_arm64
+          PLATFORM=${{ matrix.platform }}
+          BINARY=${{ matrix.binary }}
+          make -f ${BINARY/-/}.mk build-${PLATFORM/-/_}
 
-      - name: Upload Artifacts (linux-amd64)
+      - name: Upload Artifacts
         uses: actions/upload-artifact@v3
         with:
-          name: kube-trigger-${{ steps.get_version.outputs.VERSION }}-linux-amd64
-          path: bin/kube-trigger-${{ steps.get_version.outputs.VERSION }}/kube-trigger-*-linux-amd64
-
-      - name: Upload Artifacts (darwin-amd64)
-        uses: actions/upload-artifact@v3
-        with:
-          name: kube-trigger-${{ steps.get_version.outputs.VERSION }}-darwin-amd64
-          path: bin/kube-trigger-${{ steps.get_version.outputs.VERSION }}/kube-trigger-*-darwin-amd64
-
-      - name: Upload Artifacts (darwin-arm64)
-        uses: actions/upload-artifact@v3
-        with:
-          name: kube-trigger-${{ steps.get_version.outputs.VERSION }}-darwin-arm64
-          path: bin/kube-trigger-${{ steps.get_version.outputs.VERSION }}/kube-trigger-*-darwin-arm64
+          name: ${{ matrix.binary }}-${{ steps.get_version.outputs.VERSION }}-${{ matrix.platform }}
+          path: bin/${{ matrix.binary }}-${{ steps.get_version.outputs.VERSION }}/${{ matrix.binary }}-*-${{ matrix.platform }}
diff --git a/.gitignore b/.gitignore
@@ -60,3 +60,6 @@ bin
 # etcd
 default.etcd
 
+# Generated Dockerfile
+# This is automatically generated by Make depending on which image you want to build.
+Dockerfile
diff --git a/Dockerfile.in b/Dockerfile.in
@@ -13,7 +13,12 @@
 # limitations under the License.
 
 # Note: the ${BIN} needs to be replaced with the actual binary,
-# otherwise it won't work. Refer to Makefile for how it can be done.
+# otherwise it won't work. A valid Dockerfile will be generated
+# using this template. Refer to Makefile for how it can be done.
+
+# syntax = docker/dockerfile:1.2
+# You need to enable Docker BuildKit for this to work.
+# Also refer to Makefile for how it can be done.
 
 ARG BUILD_IMAGE=golang:1.17
 ARG BASE_IMAGE=gcr.io/distroless/static:nonroot
@@ -27,7 +32,8 @@ COPY go.sum go.sum
 
 ARG GOPROXY
 ENV GOPROXY=${GOPROXY}
-RUN go mod download
+RUN --mount=type=cache,target=/root/go/pkg \
+        go mod download
 
 COPY build       build
 COPY hack        hack
@@ -45,12 +51,14 @@ ARG GOFLAGS
 ARG DIRTY_BUILD
 ARG ENTRY
 
-RUN ARCH=${TARGETARCH:-${ARCH:-amd64}} \
-        OS=${TARGETOS:-${OS:-linux}}   \
-        OUTPUT=${BIN}                  \
-        VERSION=${VERSION}             \
-        GOFLAGS=${GOFLAGS}             \
-        /bin/sh build/build.sh         \
+RUN --mount=type=cache,target=/root/.cache/go-build \
+        ARCH=${TARGETARCH:-${ARCH:-amd64}}          \
+        OS=${TARGETOS:-${OS:-linux}}                \
+        OUTPUT=${BIN}                               \
+        VERSION=${VERSION}                          \
+        GOFLAGS=${GOFLAGS}                          \
+        DIRTY_BUILD=${DIRTY_BUILD}                  \
+        /bin/sh build/build.sh                      \
         ${ENTRY}
 
 FROM ${BASE_IMAGE}

diff --git a/PROJECT b/PROJECT
@@ -10,7 +10,7 @@ resources:
   controller: true
   domain: oam.dev
   group: standard
-  kind: KubeTrigger
+  kind: TriggerInstance
   path: github.com/kubevela/kube-trigger/api/v1alpha1
   version: v1alpha1
 - api:
@@ -19,7 +19,7 @@ resources:
   controller: true
   domain: oam.dev
   group: standard
-  kind: KubeTriggerConfig
+  kind: TriggerService
   path: github.com/kubevela/kube-trigger/api/v1alpha1
   version: v1alpha1
 version: "3"
diff --git a/README.md b/README.md
@@ -55,32 +55,17 @@ No matter you are running kube-trigger as standalone or in-cluster, the config f
 know the format first. We will use yaml format as an example (json and cue are also supported).
 
 ```yaml
-# A Watcher is a group of 
-#   - one Source
-#   - multiple Filters
-#   - multiple Actions
-# You can add multiple Watchers. They will run simultaneously.
-watchers:
-  - source: # One Source
-      # Which Source? (What type of event Source do you want?)
-      type: k8s-resource-watcher
-      # Source-specific configuration. Refer to each Source for details.
-      # For example, we can tell k8s-resource-watcher what resources to watch.
-      properties:
-      # ...
-    filters: # An array of Filters
-      # What Filters to use? They will be logically ANDed together.
-      - type: cue-validator
-        # Filter-specific configuration. Refer to each Filter for details.
-        properties:
-        # ...
-    actions: # An array of Actions
-      # What Actions to use? They all of them will be executed when an event happens.
-      - type: bump-application-revision
-        # Action-specific configuration. Refer to each Action for details.
-        properties:
-        # ...
-
+# A trigger is a group of Source, Filters, and Actions.
+# You can add multiple triggers.
+triggers:
+  - your-source-type:
+      # ... properties
+    filters:
+      - your-filter-0-type:
+          # ... properties
+    actions:
+      - your-action-0-type:
+          # ... properties
 ```
 
 ### Standalone
@@ -94,38 +79,32 @@ config file.
 An example config file looks like this:
 
 ```yaml
-# A Watcher is a group of Source, Filters, and Actions.
-# You can add multiple Watchers.
-watchers:
-  - source:
-      # Watch Kubernetes events.
-      type: k8s-resource-watcher
-      properties:
-        # We are interested in ConfigMap events.
-        apiVersion: v1
-        kind: ConfigMap
-        namespace: default
-        # Only watch update event.
-        events:
-          - update
+# A trigger is a group of Source, Filters, and Actions.
+# You can add multiple triggers.
+triggers:
+  - k8s-resource-watcher:
+      # We are interested in ConfigMap events.
+      apiVersion: "v1"
+      kind: ConfigMap
+      namespace: default
+      # Only watch update event.
+      events:
+        - update
     filters:
       # Filter the events above.
-      - type: cue-validator
-        properties:
+      - cue-validator:
           # Filter by validating the object data using CUE.
           # For example, we are filtering by ConfigMap names (metadata.name) from above.
           # Only ConfigMaps with names that satisfy this regexp "this-will-trigger-update-.*" will be kept.
           template: |
             metadata: name: =~"this-will-trigger-update-.*"
     actions:
       # Bump Application Revision to update Application.
-      - type: bump-application-revision
-        properties:
+      - bump-application-revision:
           namespace: default
           # Select Applications to bump using labels.
           labelSelectors:
             my-label: my-value
-
 ```
 
 Let's assume your config file is `config.yaml`, to run kube-trigger:
@@ -135,50 +114,40 @@ Let's assume your config file is `config.yaml`, to run kube-trigger:
 
 ### In-Cluster
 
-We have two CRDs: *KubeTrigger* and *KubeTriggerConfig*.
+We have two CRDs: *TriggerInstance* and *TriggerService*.
 
-- *KubeTrigger* is what creates a kube-trigger instance (similar to running `./kube-trigger` in-cluster but no config is
+- *TriggerInstance* is what creates a kube-trigger instance (similar to running `./kube-trigger` in-cluster but no config is
   provided). Advanced kube-trigger Instance Configuration (next section) can be provided in it.
-- *KubeTriggerConfig* is used to provide one or more configs (same as the config file you use when running as
-  standalone) to a *KubeTrigger* instance.
+- *TriggerService* is used to provide one or more configs (same as the config file you use when running as
+  standalone) to a *TriggerInstance*.
 
-So we know *KubeTriggerConfig* is what actually provides a config, this is what we will be discussing.
+So we know *TriggerService* is what actually provides a config, this is what we will be discussing.
 
 ```yaml
-# You can find this file in config/samples/standard_v1alpha1_kubetriggerconfig.yaml
+# You can find this file in config/samples/standard_v1alpha1_triggerservice.yaml
 apiVersion: standard.oam.dev/v1alpha1
-kind: KubeTriggerConfig
+kind: TriggerService
 metadata:
   name: kubetrigger-sample-config
   namespace: default
 spec:
-  # Provide this config to these (using selectors) KubeTrigger instances.
-  # KubeTrigger should be created first, then when you apply this KubeTriggerConfig
-  # the KubeTrigger instances selected by selectors will be given the config
-  # defined in this file.
-  # Label selector (the labels in KubeTrigger).
   selector:
     app: kubetrigger-sample
-  # Familiar? This section is exactly the same as what we have seen above.
-  watchers:
-    - source:
-        type: k8s-resource-watcher
-        properties:
-          apiVersion: "v1"
-          kind: ConfigMap
-          namespace: default
-          events:
-            - update
+  triggers:
+    - k8s-resource-watcher:
+        apiVersion: "v1"
+        kind: ConfigMap
+        namespace: default
+        events:
+          - update
       filters:
-        - type: cue-validator
-          properties:
+        - cue-validator:
             template: |
               // Filter by object name.
               // I used regular expressions here.
               metadata: name: =~"this-will-trigger-update-.*"
       actions:
-        - type: bump-application-revision
-          properties:
+        - bump-application-revision:
             namespace: default
             labelSelectors:
               my-label: my-value
@@ -293,7 +262,7 @@ Default: `100`
 - [x] Make the configuration as CRD, launch new process/pod for new watcher
 - [x] Notification for more than one app: selector from compose of Namespace; Labels; Name
 - [x] Refine README, quick starts
-- [ ] Refactor CRD according to [#2](https://github.com/kubevela/kube-trigger/issues/2)
+- [x] Refactor CRD according to [#2](https://github.com/kubevela/kube-trigger/issues/2)
 
 ### v0.0.1-beta.x
 

diff --git a/api/v1alpha1/groupversion_info.go b/api/v1alpha1/groupversion_info.go
@@ -38,6 +38,6 @@ var (
 )
 
 var (
-	KubeTriggerKind       = reflect.TypeOf(KubeTrigger{}).Name()
-	KubeTriggerConfigKind = reflect.TypeOf(KubeTriggerConfig{}).Name()
+	KubeTriggerKind       = reflect.TypeOf(TriggerInstance{}).Name()
+	KubeTriggerConfigKind = reflect.TypeOf(TriggerService{}).Name()
 )
-Original file line number
+Diff line change
@@ Expand Up / @@ -60,3 +60,4 @@ bin @@
     .github
     docs
     examples
+    .git