gitlab+gitlab-runner 实现CI/CD

本文介绍如何使用GitLab和GitLab-Runner实现CI/CD自动化部署流程。通过配置.gitlab-ci.yml文件,根据不同分支执行不同的脚本,实现代码自动化部署。并详细介绍了yml文件的编写及Runner的设置。

一、前言

        前面我用docker 部署了gitlab 和 gitlab-runner。然后这一篇,我们就要通过gitlab 和gitlab-runner 来实现CI/CD代码自动化部署流程。

        大致流程就是,往分支发布代码,yml文件里配置不同分支执行不通脚本。

二、编写yml 文件

        首先,我们在我们的项目代码里,写一个 .gitlab-ci.yml 文件。别的大家可以自己查一下,我这里写了比较简单的。内容如下:

stages:            # 定义pipeline的全部阶段(stage)
  - develop        # 阶段名,自己定义
  - main 

test_branch:           # 作业名称,自己定义        
  stage: develop   # 阶段名,对应stages里的阶段名
  only:            # 定义分支,并为该分支单独创建工作
    - develop
  script:          # 执行脚本,可以自己写,这里只是看一下效果
    - echo 'This is develop'

master_branch:
  stage: main
  only:
    - main
  script:
    - echo 'This branch is main'

三、打开gitlab 上 Runner 的设置

        Run untagged jobs 这行一定要勾上,因为runner和job匹配的规则是,runner的tag和项目的tag要相同,而我的项目里没有标注tag。所以,如果不把这个选项加上会导致,不触发runner。

 四、测试

        分别测试,更新不同分支代码,是否会执行不同脚本。gitlab-runner在执行脚本时,用的是系统上 gitlab-runner 这个用户去执行的,所以要注意权限问题。(切记)

        我在gitlab上test项目中创建了两个分支,分别是develop(测试) 分支,main(主)分支。

      1. 更新测试分支代码

        在本地,往gitlab上推送更新的代码,然后上gitlab,在CI/CD 上我们可以看到pipeline有一次最近提交记录,分支为develop。点 Jobs可以看到 runner 脚本执行过程,从下面第三张截图上可以看到,它只执行了test_beanch工作让它执行的脚本。master_branch 这个作业的脚本没执行,因为这个作业指定的分支为mian,而mian分支没更新,所以没执行。

         2. 更新main分支

        那怎么让它执行master_branch作业的脚本呢,我们只要把develop分支合并到main分支,main分支上的代码更新后,它就会执行了。

        我们更新了develop分支后,gitlab会问你,要不要创建合并请求。然后我们点创建合并请求。然后同意就好了,详细的就不说了,直接看结果。

        我们可以看到它输出的是:This branch is main 。

 

<think>好的,我现在要解决用户在GitLab CI/CD中遇到的cp命令错误问题,具体是执行cp时无法创建.m2目录,提示“No such file or directory”。我需要仔细分析可能的原因,并提供解决方案。 首先,用户提到的问题是在使用cp命令时发生的,目标目录是.m2,但系统提示该目录不存在。这通常是因为目标目录的父目录不存在,或者当前用户没有权限创建该目录。在CI/CD的环境中,尤其是像GitLab Runner这样的环境,默认的工作目录可能是一个临时目录,结构可能与本地不同。 接下来,我需要回忆GitLab CI/CD的工作流程。根据用户提供的引用内容[^3],GitLab CI/CD的阶段是按顺序执行的,每个作业可能在不同的环境下运行。如果某个作业需要特定的目录结构,必须在执行命令前确保目录存在。例如,在安装或构建阶段,可能需要手动创建目录。 然后,考虑.m2目录的作用。.m2通常是Maven的本地仓库目录,用于存储依赖项。在构建Java项目时,Maven会默认在用户主目录下创建.m2。但在CI环境中,可能没有用户主目录,或者当前工作目录不是用户主目录,导致.m2目录不存在。因此,用户可能在尝试复制文件到.m2时,该目录尚未创建,导致错误。 接下来,解决方案可能包括在运行cp命令前,先创建目标目录。使用mkdir -p命令可以递归创建目录,即使父目录不存在也能成功。例如,在复制文件之前执行`mkdir -p ~/.m2`,确保目录存在。或者,如果目标目录是相对路径,需要确认当前工作目录是否正确,必要时使用绝对路径。 另外,权限问题也可能导致无法创建目录。虽然CI环境通常有足够的权限,但在某些配置下可能需要明确设置权限。但这种情况较少见,可能优先考虑目录是否存在的问题。 还需要检查cp命令的具体参数是否正确。例如,如果使用了递归复制选项`-r`,可能需要调整参数。但根据错误信息,问题更可能在于目录不存在,而不是参数错误。 最后,根据用户提供的引用[^3],作业之间的依赖关系可能影响目录的创建。例如,如果某个作业负责创建目录,而当前作业没有正确依赖它,可能导致目录未生成。需要确保创建目录的步骤在复制文件之前执行,或者在同一作业中按顺序执行。 总结可能的解决方案步骤: 1. 在执行cp命令前,使用mkdir -p创建目标目录。 2. 确认目标路径是否正确,可能需要使用绝对路径。 3. 检查作业依赖关系,确保目录创建步骤在复制之前完成。</think>在GitLab CI/CD中遇到`cp`命令无法创建`.m2`目录的问题,通常是因为目标目录的父路径不存在或权限不足。以下是逐步解决方案: 1. **手动创建目录** 在执行`cp`命令前,使用`mkdir -p`递归创建目录: ```yaml script: - mkdir -p ~/.m2 # 创建用户主目录下的.m2 - cp -r path/to/source/files ~/.m2/ ``` 如果目标路径是相对路径(如`./.m2`),需确保当前工作目录正确,或改用绝对路径。 2. **明确路径与权限** - 检查`.m2`目录的路径是否被环境变量(如`$HOME`)动态影响,建议使用绝对路径: ```yaml - mkdir -p /path/to/.m2 - cp -r source /path/to/.m2/ ``` - 若权限不足,尝试添加`sudo`(需Runner配置允许): ```yaml - sudo mkdir -p ~/.m2 && sudo chmod -R 777 ~/.m2 ``` 3. **依赖作业与阶段顺序** 根据引用[^3],若目录创建依赖其他作业,需通过`needs`或`dependencies`确保顺序: ```yaml stages: - prepare - copy create_dir_job: stage: prepare script: - mkdir -p ~/.m2 copy_files_job: stage: copy needs: ["create_dir_job"] # 显式依赖 script: - cp -r source ~/.m2/ ``` 4. **检查Runner环境** GitLab Runner默认使用临时工作目录,可能每次作业都是全新环境。若需保留目录,可通过`cache`或`artifacts`跨作业传递: ```yaml cache: paths: - ~/.m2/ ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值