Gitlab CI/CD (二)语法学习

预定义常量

最常用的两个

  1. $GITLAB_USER_LOGIN and $CI_COMMIT_BRANCH
常量名 含义
$GITLAB_USER_LOGIN 触发当前Pipeline的用户名
$CI_COMMIT_BRANCH 当前提交所在分支
$CI_DEFAULT_BRANCH Gitlab 项目默认分支
$CI_PIPELINE_SOURCE 表示当前Pipeline由什么事件触发(例如:merge_request_event 表示由MR 触发,push 表示由常规的代码推送触发,web表示Gitlab UI 点击run pipeline 触发)

基础语法

stage

  • stage describes the sequential execution of jobs. If there are runners available, jobs in a single stage run in parallel.

(stage 描述一序列的执行任务,如果runners是可用的,任务在单一stage中并行运行)

  • stage and stages: The most common pipeline configurations group jobs into stages. Jobs in the same stage can run in parallel, while jobs in later stages wait for jobs in earlier stages to complete. If a job fails, the whole stage is considered failed and jobs in later stages do not start running. 「stage」和「stages」 : 大部分常见的流水线配置一组job到stages.Job在相同的stage可以并行运行,后面stage的job 会等待早期stage的job的完成。如果一个job 失败,整个stage被认为失败,并且后面stage的job 不会再运行

needs

  • Use the needs keyword to run jobs out of stage order, to increase pipeline speed and efficiency。 (使用needs 关键词,使得任务脱离stage的顺序执行),提升流水线的速度和效率。

rules

  • Use the rules keyword to specify when to run or skip jobs. The only and except legacy keywords are still supported, but can't be used with rules in the same job. 使用Rules关键词指定何时运行,跳过任务,「only」和「except」这两个传统关键词仍然被支持使用,但是不能和「rules」关键词在相同的job中使用。

使用示例:

yaml 复制代码
job:
  script: echo "Hello"
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'   # 只有 main 分支跑
    - if: '$CI_COMMIT_BRANCH == "dev"'    # dev 分支也跑
    - when: never                         # 其他情况不跑
  1. when 支持 $VARIABLE 表达式 取值 | 变量名 | 含义 | | --- | --- | | always | | | never | | | manual | | | delayed | |

only和except(跟rules作用相同,逐步被弃用,推荐用rules)

yaml 复制代码
job:
  script: echo "Hello"
  only:
    - main        # 只在 main 分支跑
  except:
    - tags        # 打 tag 时不跑

cache和artifacts

  • Keep information across jobs and stages persistent in a pipeline with cache and artifacts. These keywords are ways to store dependencies and job output, even when using ephemeral runners for each job.

在一个流水线中使用「cache」和「artifacts」保持信息在跨jobs和stages 持久化。这些关键词是存储依赖和工作输出的方法,即使每项工作使用短暂的运行器

Jobs are self-contained and do not share resources with each other. If you want files generated in one job to be used in another job, you must save them as artifacts first. Then later jobs can retrieve the artifacts and use the generated files.

default

  • Use the default keyword to specify additional configurations that are applied to all jobs. This keyword is often used to define before_script and after_script sections that should run on every job. 使用default 关键词指定额外的配置针对所有的工作。这个关键词经常被用在定义「before_script」和『after_script』中

image

Tell the runner which Docker container to use to run the job in. The runner:

  1. Downloads the container image and starts it.
  2. Clones your GitLab project into the running container.
  3. Runs the script commands, one at a time.

告诉Runner job应该在 哪个Docker 容器下被运行

  1. 下载Container 镜像,并运行
  2. 克隆你的Gitlab 项目到运行的容器
  3. 运行script 命令,一次一个

Gitlab Pages

  • GitLab Pages: To host your static site, you will use GitLab Pages.

  • Add a job that fetches the built site and deploys it. When using GitLab Pages, the job is always named pages. The artifacts from the build-job are fetched automatically and extracted into the job. Pages looks for the site in the public/ directory though, so add a script command to move the site to that directory. 添加一个job去获取构建的站点并且部署它。当使用Gitlab Pages,job总是被命名为「pages」 .从「build-job」中生成的产物会被自动获取并且提取到pages这个job 中。Pages 通过「/public」目录寻找站点,因此「script」中需要添加一个命令,将站点移动到「/public」目录中

  • Add a stages section, and define the stages for each job. build-job runs first in the build stage, and pages runs after in the deploy stage.

添加一个「stages」节点,定义每项job的stage.首先会运行「build」stage中的「build-job」,后面会接着运行「deploy」stage中的 「pages」

dependencies

  1. 不写默认下载统一Pipline 中之前所有job的产物
  2. dependenies: build 标识只下载build(job)中的产物
  3. dependenies: [] 表示不下载任何产物,加快构建速度

-

符号 「 - 」

  1. 可以引用 上面定义的job 名称
  2. 在script 节点下可以直接执行 shell 命令脚本
  3. 可以指定paths: 的目录:例如: - "public/"
  4. 「- if」: 布尔判断

allow_failure

表示当前任务的执行成功失败是否会影响后续流水线的执行,如果true ,表示后续流水线继续执行,false:表示整个流水线终止

.

  • Hidden jobs: Jobs that start with . are never added to a pipeline. Use them to hold configuration you want to reuse.

可以命名为.standard-rules

以「.」开头的job 是隐藏job,永远不会被添加到流水线。使用他们持有想要去重用的配置

extends

  • extends: Use extends to repeat configuration in multiple places, often from hidden jobs. If you update the hidden job's configuration, all jobs extending the hidden job use the updated configuration.

使用 extends 在多个地方重用隐藏job中配置.如果你更新了隐藏job的配置,所有继承自隐藏job的job 将使用更新后的配置

interruptible

  • interruptible: true → 如果同一分支或相同类型的新 Pipeline 触发,旧 Job 会被自动取消(节省 Runner 资源)
  • 默认是 false → Job 不会被自动取消,即使触发了新 Pipeline,旧 Job 仍然继续执行

variables

  • 配置 CI/CD 行为

    • 可以设置 SDK 版本、构建工具版本等
    • Job 脚本中用 $VAR_NAME 调用
  • 跨 Job 传递信息

    • 例如 API 密钥、版本号、构建参数
  • 条件控制

    • 结合 rules:only/except,根据变量决定是否执行 Job

before_script

  • 环境准备

    • 安装依赖(SDK、工具、包管理器等)
    • 配置 PATH 或其他环境变量
  • 初始化项目

    • 创建目录
    • 确保可执行权限(如 chmod +x ./gradlew
  • 可被全局或单 Job 使用

    • 定义在全局:所有 Job 都会执行
    • 定义在 Job 里:只对该 Job 生效

allow_failure

  • 允许 Job 失败但不让 Pipeline 失败

    • 设置 allow_failure: true 的 Job,即使执行失败,也不会标记整个 Pipeline 为失败
    • Pipeline 状态显示 "passed with warnings"黄色状态
  • 常用场景

    • 可选的测试 Job(UI 测试、性能测试)
    • 某些实验性构建或检查
    • 手动触发的 Job
  • 默认行为

    • allow_failure: false(默认值)
    • Job 失败 → Pipeline 失败

Android 通用脚本

bash 复制代码
# GitLab CI/CD Android 构建模板(macOS Runner + OpenJDK 17 + SDK 缓存)

image: openjdk:17-jdk
# 定义变量
variables:
  ANDROID_COMPILE_SDK: "35"
  ANDROID_BUILD_TOOLS: "35.0.0"
  ANDROID_SDK_TOOLS: "13114758"
  ANDROID_HOME: "${CI_PROJECT_DIR}/android-sdk-root"

stages:
  - build

# 缓存 Android SDK,避免每次重新下载
cache:
  key: android-sdk
  paths:
    - android-sdk-root/

# Android 打包SDK 环境检查,下载,licenses 同意
before_script:
  # 安装必要依赖
  - brew install wget unzip coreutils || true

  # 创建 SDK 根目录
  - mkdir -p "$ANDROID_HOME"

  # 仅在 SDK 不存在时下载
  - if [ ! -d "$ANDROID_HOME/cmdline-tools/tools" ]; then
    echo "Downloading Android SDK command line tools...";
    wget --no-verbose --output-document=$ANDROID_HOME/cmdline-tools.zip https://dl.google.com/android/repository/commandlinetools-mac-${ANDROID_SDK_TOOLS}_latest.zip;
    unzip -q -d "$ANDROID_HOME/cmdline-tools" "$ANDROID_HOME/cmdline-tools.zip";
    gmv -T "$ANDROID_HOME/cmdline-tools/cmdline-tools" "$ANDROID_HOME/cmdline-tools/tools";
    else
    echo "Android SDK already exists, skip download.";
    fi

  # 设置 PATH
  - export PATH=$PATH:$ANDROID_HOME/cmdline-tools/latest/bin:$ANDROID_HOME/cmdline-tools/tools/bin

  # 检查 sdkmanager
  - sdkmanager --version

  # 接受所有许可
  - yes | sdkmanager --licenses > /dev/null || true

  # 安装必须的 SDK 包
  - sdkmanager "platforms;android-${ANDROID_COMPILE_SDK}" "platform-tools" "build-tools;${ANDROID_BUILD_TOOLS}"

  # 确保 gradlew 可执行
  - chmod +x ./gradlew

# 打debug 包
assembleDebug:
  stage: build
  interruptible: true
  tags:
    - macos
  script:
    - ./gradlew clean assembleDebug
    - mkdir -p output/debug
    - cp app/build/outputs/apk/debug/*.apk output/debug
  artifacts:
    paths:
      - output/debug
# 打Release 包
assembleRelease:
  stage: build
  interruptible: true
  tags:
    - macos
  script:
    - ./gradlew clean assembleRelease
    - mkdir -p output/release
    - cp app/build/outputs/apk/release/*.apk output/release
  artifacts:
    paths:
      - output/release
  when: manual
  allow_failure: false
相关推荐
裸奔的大金毛7 小时前
Tekton - 自定义镜像配置git仓库克隆
git·ci/cd·devops·tekton
戎码江湖3 天前
使用CI/CD部署项目(前端Nextjs)
ci/cd·自动部署项目·自动部署前端项目·github部署项目·一键部署项目
wallflower20203 天前
从零到全流程 CI/CD:多技术栈项目自动化部署实战与优化指南
ci/cd·github
小薛博客4 天前
17、DevOps持续集成、持续部署
运维·ci/cd·devops
切糕师学AI4 天前
持续集成和持续交付 (CI/CD) 工具——Jenkins
运维·ci/cd·jenkins
会飞的小蛮猪5 天前
Jenkins运维之路(自动获得分支tag&自动构建)
运维·经验分享·ci/cd·jenkins
幂简集成5 天前
基于 Gemini 的 CI/CD 自动化测评 API 集成实战教程
运维·ci/cd·自动化
奋进的电子工程师5 天前
汽车软件研发智能化:AI在CI/CD中的实践
人工智能·ci/cd·汽车·软件工程·软件构建·代码规范
戎码江湖5 天前
使用CI/CD部署后端项目(gin)
ci/cd·golang·gin·后端自动部署项目·自动化部署项目