Group items tagged

Review apps are deployed using the auto-deploy-app chart with Helm, which can be customized.

Apps are deployed using the auto-deploy-app chart with Helm.

If you are also using Auto Review Apps and Auto Deploy and choose to provide your own Dockerfile, make sure you expose your application to port 5000 as this is the port assumed by the default Helm chart.

If your project has a Dockerfile in the root of the project repo, Auto DevOps will build a Docker image based on the Dockerfile rather than using buildpacks.

Bundled chart - If your project has a ./chart directory with a Chart.yaml file in it, Auto DevOps will detect the chart and use it instead of the default one.

Create a project variable AUTO_DEVOPS_CHART with the URL of a custom chart to use or create two project variables AUTO_DEVOPS_CHART_REPOSITORY with the URL of a custom chart repository and AUTO_DEVOPS_CHART with the path to the chart.

Auto DevOps detects variables where the key starts with K8S_SECRET_ and make these prefixed variables available to the deployed application, as environment variables.

if you update an application secret without changing any code then manually create a new pipeline, you will find that any running application pods will not have the updated secrets.

Variables with multiline values are not currently supported

The normal behavior of Auto DevOps is to use Continuous Deployment, pushing automatically to the production environment every time a new pipeline is run on the default branch.

Once you get to 100%, you cannot scale down, and you’d have to roll back by redeploying the old version using the rollback button in the environment page.

With INCREMENTAL_ROLLOUT_MODE set to manual and with STAGING_ENABLED

After the pipeline completes, Kubernetes will no longer be able to access the Container Registry.

GitLab CI 的環境變數主要有三個來源，優先度高到低依序為Settings > CI/CD 介面定義的變數gitlab_ci.yml 定義環境變數GitLab 預設環境變數

Auto Devops 裡面的做法，用 herokuish 提供的 Image 來打包專案

If you work on a feature branch for more than a few hours, it is good to share the intermediate result with the rest of the team.

if you want to merge into a protected branch, assign your merge request to someone with maintainer permissions.

If there is no issue yet, create the issue

The issue title should describe the desired state of the system.

Merge requests always create a merge commit, even when the branch could be merged without one. This merge strategy is called “no fast-forward” in Git.

At any time, there is at most one branch for every issue.

It is possible that one feature branch solves more than one issue.

you should never rebase commits you have pushed to a remote server.

never rebase commits authored by other people.

Sometimes you can reuse recorded resolutions (rerere), but merging is better since you only have to resolve conflicts once.

Most feature branches should take less than one day of work.

When creating a feature branch, always branch from an up-to-date master.

When a CI job runs in a Docker container, the before_script, script, and after_script commands run in the /builds/<project-path>/ directory. Your image may have a different default WORKDIR defined. To move to your WORKDIR, save the WORKDIR as an environment variable so you can reference it in the container during the job’s runtime.

To override the entrypoint of a Docker image, define an empty entrypoint in the .gitlab-ci.yml file, so the runner does not start a useless shell layer. However, that does not work for all Docker versions. For Docker 17.06 and later, the entrypoint can be set to an empty value. For Docker 17.03 and earlier, the entrypoint can be set to /bin/sh -c, /bin/bash -c, or an equivalent shell available in the image.

The runner expects that the image has no entrypoint or that the entrypoint is prepared to start a shell command.

Merging into master and then cherry-picking into release is called an “upstream first” policy

If you open the merge request but do not assign it to anyone, it is a “Work In Progress” merge request.

Start the title of the merge request with “[WIP]” or “WIP:” to prevent it from being merged before it’s ready.

you should never rebase commits you have pushed to a remote server.

never rebase commits authored by other people.

it is a bad idea to rebase commits that you have already pushed.

people avoid merge commits by just using rebase to reorder their commits after the commits on the master branch. Using rebase prevents a merge commit when merging master into your feature branch, and it creates a neat linear history.

keep your feature branches short-lived.

Commit often and push frequently

A commit message should reflect your intention, not just the contents of the commit.

Testing before merging

When creating a feature branch, always branch from an up-to-date master

do not mix only/except jobs with rules jobs in the same pipeline.

With only, individual keys are logically joined by an AND

With except, individual keys are logically joined by an OR

images are saved in the host registry, we can benefit from Docker layer caching

The Docker socket binding technique means making a volume of /var/run/docker.sock between host and containers.

To avoid building a Docker image at each job, it can be built in a first job, pushed to the image registry provided by GitLab, and pulled in the next jobs.

Docker in Docker works well, but has its drawbacks, like Docker layer caching which needs some more commands to be used.

an image is made of multiple layers, and we can accelerate its build by using layers cache from the previous image version.

by using Docker-in-Docker, we get a fresh Docker instance per job which local registry is empty.

Cache in CI/CD is about saving directories or files across pipelines.

We set the directories to cache in the job settings with a key to share the cache per branch and stage.

we docker push after the build, then we docker pull if needed in the next jobs.