Merge branch 'feature/gb/add-serverless-cicd-template' into 'master'

Simplify CI/CD configuration on serverless projects

Closes #57405

See merge request gitlab-org/gitlab-ce!25523
This commit is contained in:
Grzegorz Bizon 2019-03-05 09:16:32 +00:00
commit 960101c20b
4 changed files with 112 additions and 38 deletions

View file

@ -0,0 +1,5 @@
---
title: Simplify CI/CD configuration on serverless projects
merge_request: 25523
author:
type: added

View file

@ -114,28 +114,35 @@ Follow these steps to deploy a function using the Node.js runtime to your Knativ
- Public, continue to the next step. - Public, continue to the next step.
- Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope. - Private, you will need to [create a GitLab deploy token](../../deploy_tokens/index.md#creating-a-deploy-token) with `gitlab-deploy-token` as the name and the `read_registry` scope.
1. `.gitlab-ci.yml`: This template allows to define the stage, environment, and 1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions.
image to be used for your functions. It must be included at the root of your repository: It must be included at the root of your repository:
```yaml ```yaml
stages: include:
- deploy template: Serverless.gitlab-ci.yml
functions: functions:
stage: deploy extends: .serverless:deploy:functions
environment: test environment: production
image: gcr.io/triggermesh/tm:v0.0.9
script:
- tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" --push
- tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull
- tm -n "$KUBE_NAMESPACE" deploy --wait
``` ```
The `gitlab-ci.yml` template creates a `Deploy` stage with a `functions` job that invokes the `tm` CLI with the required parameters. This `.gitlab-ci.yml` creates a `functions` job that invokes some
predefined commands to deploy your functions to your cluster.
2. `serverless.yml`: This file contains the metadata for your functions, `Serverless.gitlab-ci.yml` is a template that allows customization.
such as name, runtime, and environment. It must be included at the root of your repository. The following is a sample `echo` function which shows the required structure for the file. You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions). You can either import it with `include` parameter and use `extends` to
customize your jobs, or you can inline the entire template by choosing it
from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through
the user interface.
2. `serverless.yml`: this file contains the metadata for your functions,
such as name, runtime, and environment.
It must be included at the root of your repository.
The following is a sample `echo` function which shows the required structure
for the file.
You can find the relevant files for this project in the [functions example project](https://gitlab.com/knative-examples/functions).
```yaml ```yaml
service: my-functions service: my-functions
@ -234,32 +241,22 @@ Add the following `.gitlab-ci.yml` to the root of your repository
(you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above): (you may skip this step if you've previously cloned the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) mentioned above):
```yaml ```yaml
stages: include:
- build template: Serverless.gitlab-ci.yml
- deploy
build: build:
stage: build extends: .serverless:build:image
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
only:
- master
script:
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $CI_REGISTRY_IMAGE
deploy: deploy:
stage: deploy extends: .serverless:deploy:image
image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
only:
- master
environment: production
script:
- echo "$CI_REGISTRY_IMAGE"
- tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
``` ```
`Serverless.gitlab-ci.yml` is a template that allows customization.
You can either import it with `include` parameter and use `extends` to
customize your jobs, or you can inline the entire template by choosing it
from **Apply a template** dropdown when editing the `.gitlab-ci.yml` file through
the user interface.
### Deploy the application with Knative ### Deploy the application with Knative
With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to

View file

@ -0,0 +1,41 @@
# GitLab Serverless template
image: alpine:latest
stages:
- build
- deploy
.serverless:build:image:
variables:
DOCKERFILE: "Dockerfile"
stage: build
image:
name: gcr.io/kaniko-project/executor:debug
entrypoint: [""]
only:
refs:
- master
script:
- echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/$DOCKERFILE --destination $CI_REGISTRY_IMAGE
.serverless:deploy:image:
stage: deploy
image: gcr.io/triggermesh/tm@sha256:e3ee74db94d215bd297738d93577481f3e4db38013326c90d57f873df7ab41d5
only:
refs:
- master
environment: development
script:
- echo "$CI_REGISTRY_IMAGE"
- tm -n "$KUBE_NAMESPACE" --config "$KUBECONFIG" deploy service "$CI_PROJECT_NAME" --from-image "$CI_REGISTRY_IMAGE" --wait
.serverless:deploy:functions:
stage: deploy
environment: development
image: gcr.io/triggermesh/tm:v0.0.9
script:
- tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password "$CI_JOB_TOKEN" --push
- tm -n "$KUBE_NAMESPACE" set registry-auth gitlab-registry --registry "$CI_REGISTRY" --username "$CI_DEPLOY_USER" --password "$CI_DEPLOY_PASSWORD" --pull
- tm -n "$KUBE_NAMESPACE" deploy --wait

View file

@ -3,9 +3,40 @@
require 'spec_helper' require 'spec_helper'
describe "CI YML Templates" do describe "CI YML Templates" do
Gitlab::Template::GitlabCiYmlTemplate.all.each do |template| ABSTRACT_TEMPLATES = %w[Serverless].freeze
it "#{template.name} should be valid" do
expect { Gitlab::Ci::YamlProcessor.new(template.content) }.not_to raise_error def self.concrete_templates
Gitlab::Template::GitlabCiYmlTemplate.all.reject do |template|
ABSTRACT_TEMPLATES.include?(template.name)
end
end
def self.abstract_templates
Gitlab::Template::GitlabCiYmlTemplate.all.select do |template|
ABSTRACT_TEMPLATES.include?(template.name)
end
end
describe 'concrete templates with CI/CD jobs' do
concrete_templates.each do |template|
it "#{template.name} template should be valid" do
expect { Gitlab::Ci::YamlProcessor.new(template.content) }
.not_to raise_error
end
end
end
describe 'abstract templates without concrete jobs defined' do
abstract_templates.each do |template|
it "#{template.name} template should be valid after being implemented" do
content = template.content + <<~EOS
concrete_build_implemented_by_a_user:
stage: build
script: do something
EOS
expect { Gitlab::Ci::YamlProcessor.new(content) }.not_to raise_error
end
end end
end end
end end