Commit 960101c2 authored by Grzegorz Bizon's avatar Grzegorz Bizon

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
parents 1caa760f 248fe72c
---
title: Simplify CI/CD configuration on serverless projects
merge_request: 25523
author:
type: added
......@@ -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.
- 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
image to be used for your functions. It must be included at the root of your repository:
1. `.gitlab-ci.yml`: this defines a pipeline used to deploy your functions.
It must be included at the root of your repository:
```yaml
stages:
- deploy
include:
template: Serverless.gitlab-ci.yml
functions:
stage: deploy
environment: test
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
extends: .serverless:deploy:functions
environment: production
```
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.
`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.
2. `serverless.yml`: this file contains the metadata for your functions,
such as name, runtime, and environment.
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).
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
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):
```yaml
stages:
- build
- deploy
include:
template: Serverless.gitlab-ci.yml
build:
stage: build
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
extends: .serverless:build:image
deploy:
stage: deploy
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
extends: .serverless:deploy:image
```
`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
With all the pieces in place, the next time a CI pipeline runs, the Knative application will be deployed. Navigate to
......
# 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
......@@ -3,9 +3,40 @@
require 'spec_helper'
describe "CI YML Templates" do
Gitlab::Template::GitlabCiYmlTemplate.all.each do |template|
it "#{template.name} should be valid" do
expect { Gitlab::Ci::YamlProcessor.new(template.content) }.not_to raise_error
ABSTRACT_TEMPLATES = %w[Serverless].freeze
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
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment