GitLab CI에서 지정된 브랜치의 병합 요청을 만들 때(병합 전) 파이프라인을 이동하는 방법

공유 개발/스테이징/프로덕션과 환경을 구분하고 있습니다 만, 공유 개발까지는 디버그 빌드 때문에 스루되고 있던 에러가 스테이징에의 배포시의 프로덕션 빌드로 에러가 되어 배포에 실패한다고 하는 것이 많이 있습니다. (사용하지 않는 변수가 존재하는 등...)

그런 어쩔 수 없는 에러를 해결하기 위해서 또 로컬 환경으로부터 다시 하는 것은 시간의 낭비구나~. 좀 더 빠른 단계에서 붕괴하고 싶다 ~. 라고 생각해 조사해 보면, 지정 브랜치의 병합 리퀘스트 작성시에 파이프라인을 움직이는 방법이 있었으므로 시험해 보았습니다.

〇환경


  • 로컬 환경(feature/~브랜치)
  • 공유 개발 환경 (develop 브랜치)
  • 스테이징 환경(staging 브랜치) ※HEROKU
  • 프로덕션 환경 (master 브랜치)    ※HEROKU

  • 프로젝트 구성



    Node.js+Angular+Express.js

    〇 병합 요청을 만들 때 파이프라인을 실행하는 방법



    GitLab Docs에 실렸습니다.

    gitlab-ci.yml
    test:
      stage: test
      script: ./test
      only:
      - merge_requests
    

    이제 병합 요청을 만들 때 파이프라인이 실행됩니다!

    하지만. . .
    이번에는 develop 브랜치에 병합 요청을 만들 때만 실행하고 싶습니다. 위의 지정을 사용하면 모든 브랜치에 병합 요청을 만들 때 파이프 라인이 실행됩니다 .

    ◆ 브랜치 지정



    여러분이 찾고 있다면 Stack Overflow 기사에 썼습니다.
    $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "develop" 와 같이 지정할 수 있는 것 같습니다!

    gitlab-ci.yml
    test:
      stage: test
      script: ./test
      only:
        refs:
            - merge_requests
        variables:
            - $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == "develop"
    

    이제 develop 브랜치에 대한 병합 요청을 만들 때만 파이프라인이 실행됩니다.

    〇정리



    이런 식으로 병합 요청을 만들 때 파이프 라인을 움직일 수있었습니다.
    이제 병합 요청을 만들 때 (병합 전) 빌드 확인을 할 수 있기 때문에 손으로 돌아갈 수 없습니다
    또, 테스트의 실시도 할 수 있기 때문에, 제대로 테스트가 다니고 나서 리뷰 의뢰를 낸다고 하는 운용에 할 수 있어, 리뷰 공수의 삭감이나 데그레의 조기 발견에도 이어질까 생각합니다.

    참고



    Pipelines for Merge Requests
    In GitLab CI, is there a variable for a Merge Request's target branch?

    좋은 웹페이지 즐겨찾기