Unified Declarative CI/CD

    KubeVela introduced standalone workflow in version v1.6 that can be used independently, which can be used to orchestrate the process between CI steps and application delivery. Different from the workflow in the KubeVela application, it is one-time and does not manage resources. Even if the workflow is deleted, the created resources will not be deleted.

    tip

    Apply the following workflow:

    The workflow has four steps in total:

    1. Create a secret with Git token, which is used to pull the code from the private repository to build the image. If your repository is public, you can skip this step. You can also skip this step and use the kubectl create secret generic git-token --from-literal='GIT_TOKEN=<your-token>' command to create the secret.
    2. Create a secret with the image registry token to push the image to your image registry. You can also skip this step and use kubectl create secret docker-registry docker-regcred --docker-server=https://index.docker.io/v1/ --docker-username=<your-username> -- docker-password=<your-password> command to create the secret.
    3. Use the build-push-image step type to build and push the image. This step will use the specified Git url and the code in its branch to build the image. You can also directly specify in the context field. The bottom layer of this step will use for image building. During the building, you can use vela workflow logs build-push-image --step build-push to view the log of the step. Note that this step has an input from context.image, which will override the image field in properties. As you can see, we currently declare image: my-registry/test-image:v2 in the context. When we need to reuse this workflow to build a new image version, we only need to update the data in the context to update the entire process.
    4. In the last step, the image version in context.image will be used to publish the application. When the application starts, you can use vela port-forward my-app 8080:80 to check the result.

    Unified Declarative CI/CD - 图2

    You can also directly build the image in the application, and use the newly built image in the component. Apply the following application:

    1. apiVersion: core.oam.dev/v1beta1
    2. kind: Application
    3. metadata:
    4.   name: build-push-image
    5.   namespace: default
    6. spec:
    7.   components:
    9.     type: webservice
    10.       image: my-registry/test-image:v1
    11.       ports:
    12.         - port: 80
    13.           expose: true
    14.   workflow:
    15.     steps:
    16.     - name: build-push
    17.       type: build-push-image
    18.       properties:
    19.         # use your kaniko executor image like below, if not set, it will use default image oamdev/kaniko-executor:v1.9.1
    20.         # kanikoExecutor: gcr.io/kaniko-project/executor:latest
    21.         # you can use context with git and branch or directly specify the context, please refer to https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts
    22.         context:
    23.           branch: main
    24.         # you must align the image value with image field of the component properties
    25.         image: my-registry/test-image:v1
    26.         # specify your dockerfile, if not set, it will use default dockerfile ./Dockerfile
    27.         # dockerfile: ./Dockerfile
    28.         credentials:
    29.           image:
    30.             name: image-secret
    31.         # buildArgs:
    32.         #   - key="value"
    33.         # platform: linux/arm
    34.     - name: apply-comp
    35.       type: apply-component
    36.         component: my-web