CI/CD・Pipeline系メモ
ktbitnucket pipeline 各定義のメモ
image
コンテナイメージを指定。Docker Hubの公開イメージやプライベートイメージが利用できる
parallel
複数のstepを同時に実行する
parallelがなければstepは順次実行される
caches
キャッシュのことで、次回Pipelinesを動かした際にnpm installなどの処理を短縮できる
name
stepに名前をつけられる
artifacts
stepの成果物を後のstepで使用する為に使う
資料：
ktgitlab runnersについて
GitLab CI/CDのjob 実行主体
pipeline内でjobが実行される時、
- GitLab.com上のRunner
- GitLab Runnerをインストールしたマシン上のいずれかで実行される
種類
Shared Runner
GitLab.comのリソースを共有する形でjobを実行するRunner
GitLabがデフォルトで提供する機能・リソースを利用する為、
利用ケース
- CI/CDを気軽に試したい
- SpecificRunnerを用意するマシンリソースがない
- jobにリソースを大きく消費する処理がなく、簡単なCI/CDだけを想定している
- 一度に大量のpipeline/jobを実行したい場合
Specific Runner
GitLabRunnerを導入した環境で、tokenを用いてregisterすることでGitLabと連携してCI/CDが実行される
Project単位でjob実行環境を専有可能なRunner
- 自前のマシンリソースを利用してjobを処理したい
- 物理CPUを複数使い並列処理を行いたい
- Shared RunnerはGitLab.com上にあるため、ネットワークのボトルネックを避けたい
- jobがどの環境で実行されているのかコントロールしたい
- 限られた数のpipeline/jobをシーケンシャルに実行したい
Group Runner
Specific Runnerはproject単位だが、Group内のsubgroup, project共有可能なRunner
引用資料：
ktgitlab-ciのincludeについて
- 同じリポジトリの別ファイル
- 別リポジトリのファイル
- GitLabに同梱されている各種テンプレート
- HTTP/HTTPSでアクセスできるロケーション
からのファイルインクルードに対応
include:
- <<: *inc_prj
file: '〜/〜.yml'
引用資料：
ktGrableとは
Gradle=グレイドル
ビルドシステムの事
Groovyという言語によってビルドの手順を定義する。
(GroovyはJavaと互換性のある言語)
2004年ごろに業界にMaven（メイブン）
↓
Groovy（グルービー）というスクリプト言語で改良
↓
Java系、特にAndroid系の開発でGradleが使われている
引用記事：
ktgitlab-ci.yml job keywords
before_script
ジョブの前に実行される一連のコマンドをオーバーライドする
cache
後続の実行時にキャッシュする必要があるファイルのリスト
artifacts
成功時にジョブに添付するファイルとディレクトリのリスト
artifacts:paths ※公式より
パスにはプロジェクトディレクトリ($CI_PROJECT_DIR) からの相対パスを使用し、
直接外部にリンクできません。 globパターンと filepath.Matchをワイルドカードとして使用できます。
- expire_in：jobが期限切れになり削除される時間を指定する
when
ジョブを走らせるタイミング
- always：ジョブのステータスに関係なく実行する
- never：ジョブを実行させない
tags
ランナーの選択に使用されるタグのリストから、特定のランナーを選択する
ジョブを実行するには、ジョブにリストされているすべてのタグをランナーに割り当てる必要がある
variable
ジョブレベルでジョブ変数を定義する
- GIT_DEPTH：
gitの深さを数値化
GIT_SUBMODULE_STRATEGY
同じGitLabプロジェクト内への参照(submodule)のあるリポジトリを扱う時に使用
デフォルトではsubmoduleを引っ張らない
- none： (デフォルト): submoduleは引っ張ってこない
- normal：トップレベルのsubmoduleのみ引っ張ってくる (submodule内は解決しない)
- recursive：submoduleのsubmodule といった入れ子も解決する
rules
パイプラインにジョブを追加するかどうかを決定するjob policyを設定する方法
一致するまで、個々のルール句のリストを順番に評価する
■条件がマージリクエストの場合、
if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
■変更がデフォルトブランチ（通常はmaster）にプッシュされた場合
'$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
特に詳しく感じる記事：
解説記事：
公式(日本語)：
公式：
classmethod
ktGitLabCI/CD Jobs
各ジョブは往路ジェクトに関連付いていて、
特定のブランチ更新やマージをトリガーとしてビルドジョブやテストジョブを呼び出す事ができる
- マルチプラットフォーム
- MRとの連携
- 並列分散実行
- ロギング機能
- オートスケール
- アーティファクトの管理
GitLabのリポジトリ機能、チケット管理機能、Dockerレジストリ機能とも簡単に連携できることがメリット
ktGitLab Runner
CI/CD上から指示されたスクリプトを実行したり、
一時的にDockerコンテナを生成してジョブを実行したりするプロセス。
GitLab CI/CD
↓
各Runnerにビルド実行を要求
結果を監視する
Runner
↓
別プロセスでビルドやテストジョブを実行
ktExecutorの種類
Executor：遂行者
ジョブ実行方式の事で、RunnerをGitLab CI/CDに登録する時点でExecutorを選択する必要がある
- Shell Executor
- Docker Executor
- Virtual Box Executor
- SSH Executor
- Kubernetes Executor
ktArtifacts パラメータ
ジョブの実行結果をアーティファクトとして保存する際の定義を行う
path
成果物として保存したいアーティファクトが生成される場所を指定する
アーティファクトごとに一意の名前をつけておくと、
保存されてGitLab UIからダウンロードできる
ktdependenciesパラメータ
artifactsパラメータと同時に使う
- 特定のアーティファクトを次のステージのジョブに関連づける
- アーティファクトの受け渡しを制御することができる
- ステージで作成されたアーティファイトの共有を行わない場合はパラメータを空にすることで受け渡し処理をスキップできる
ktGitLab CI/CDで不具合
pipelineに新規Stageを導入をしたプロジェクトで、以下の不具合が発生。
949WARNING: Uploading artifacts as "archive" to coordinator... failed id= responseStatus=524 Origin Time-out status=524 token=
1950WARNING: Retrying... context=artifacts-uploader error=invalid argument
1951WARNING: Uploading artifacts as "archive" to coordinator... failed id= responseStatus=524 Origin Time-out status=524 token=
1952WARNING: Retrying... context=artifacts-uploader error=invalid argument
1953Uploading artifacts as "archive" to coordinator... ok id responseStatus=201 Created token=
言及：
ktCircle CIのOrbについて
ジョブ、コマンド、Executor などのパラメーター化
再利用が可能な設定要素をまとめた共有可能なオープンソースパッケージ
パッケージ化されたビルドコマンド/パイプライン
メリット
Orb では設定ファイルの要素をパラメーター化できる
↓
設定の大幅な簡素化が可能
公式： 参考記事：
ktCircle CIのパフォーマンスプランについて
クレジットベースの従量課金制プラン
- アクティブユーザー数 + 追加クレジット分の課金
- 同時実行ジョブ数 80
- IP アドレスの範囲機能
- セルフホストランサー
同時実行ジョブ
キューに貯めずに同時に実行できるジョブの数
コンピューティングの料金は、アクセスしたコンテナやマシンの数ではなく、
コンピューティング リソースを使用した合計時間に応じて発生
同時実行ジョブを最大化しジョブの並行処理を利用して、
キューによる待ち時間を最小化できるよう、チームにとって最適なプランを選択できる
例：
あるワークフローに実行時間 5 分のジョブが 10 個含まれている
同時に 1 つのジョブしか処理できない場合、
ジョブは順番に実行されていき、ワークフロー全体が完了するまでに 50 分
同時実行のスケーリングを利用した場合、
10 個のジョブがすべて同時に実行され、ワークフロー全体を 5 分で完了
どちらのケースでもマシン 10 台を 5 分ずつ使用しているため、合計使用時間は 50 分
利用レビュー記事：
IP アドレスの範囲機能
ランナーについて
Orb
よくある質問
ktCircle CIのOpenID Connect サポートについて
記事：
github：
ktCircle CI 環境変数一覧
ktCircle CIのワークフロー解説
ざっくりとキャッチアップした所のメモ
基本的な流れ
workflows: キーを使用し、
ジョブ名のリストから成る jobs: キーをネストすることによって定義
workflows:
version: 2
build_and_test:
jobs:
- build
- test
- 早く終わるジョブをワークフローの先頭に移動させる
依存関係は requires: キーを設定することで定義
workflows:
version: 2
build-test-and-deploy:
jobs:
- build
- test1:
requires:
- build
- test2:
requires:
- test1
- deploy:
requires:
- test2
手動承認フロー
type: approvalキーを指定したjobsを追加
filters.branches.only 指定ブランチのみが実行される
type: approval
requires:
- test1
filters:
branches:
only:
- main_branch
↑マスター、メインブランチには承認フローを導入したい場合の設定例
公式：
ktGithub ActionsのOpenID Connectについて
後で熟読する
kt::set-outputについての解説 → core.setOutput推奨
注：非推奨になっている
↓
core.setOutputが良さそう
出力パラメータに値を代入する
echo "::set-output name=NAME::VALUE"でNAMEにVALUEを代入する
ユースケース：
後のステップに値を渡したい時など
Aステップでコマンド実行
↓
BステップでAステップで実行したコマンドの標準出力をslackに通知する等
引用記事：
↑をエスケープせずに@actions/core の core.setOutput()で対応
公式：
core.setOutput：
複数行の標準出力を改行コードでエスケープして代入可能にする
ktGithub Actions マトリクスビルドについて
ワークフローを特定のパラメータの組み合わせで繰り返し実行したい時に利用する機能
ユースケース：
ライブラリのテストを複数のOS 、プログラミング言語バージョンの組み合わせで行う
見本
strategy:
matrix:
os: [ubuntu-latest, windows-latest, macos-latest]
node: [10, 12]
引用資料：Github-Actions実践入門
ktGithub Actions cronで定期実行
以下のように設定する
on:
schedule
- cron: '0 3 * * *'
引用資料：Github-Actions実践入門
ktGithub Actions 関数 hashFilesについて
hashFiles('ファイルのパス')
ファイルのパスに一致する全てのファイルのハッシュを計算
↓
ワークスペースからの相対パスとして評価され、ワークスペース外のファイルは評価されない
hashFiles('**/*.js')
ユースケース：
composerのcache等
ktGithub Actions キャッシュについて
actions/cache
ワークフロー実行中にキャッシュを扱うアクション
path：キャッシュとして保存・復元するファイルパス
- 必須
- ファイル、ディレクトリ、ワイルドカードによるパターンを複数指定可能
kye：
- 必須
restore-keys：キャッシュ復元時にkyeに一致するキャッシュが存在しなかった時に使われる一覧
- YAMLのリストではなく、改行区切りの文字で指定
cache-hit：keyに一致するキャッシュが存在 = true、存在しない = false
引用資料：Github-Actions実践入門
ktGithub Actions アーティファクト
ビルドで生成したファイルをビルド後に保存して、その情報を後続フローや他のフローに渡す機能
actions/upload-artifact アップロードアクション
- name：アーティファクトの名前 省略するとデフォルトでartifactという名前になる
- path：アーティファクトとしてアップロードするファイル、ディレクトリ
- 必須
- 相対パスを指定した時はワークスペースからの相対パスと判定される
- ワイルドカードを利用可能
actions/download-artifact ダウンロードアクション
uploadジョブであげたファイルをdownloadジョブ中でダウンロードして使用できる
- name：アーティファクトの名前 省略するとデフォルトでartifactという名前になる
- path：アーティファクトをダウンロードして展開する先のファイルパス
例：
uses: actions/upload-artifact@v2
引用資料：Github-Actions実践入門
ktGithub Actions キャッシュとアーティファクトの違い
キャッシュ：
ジョブやワークフローの複数の実行の間でファイルを再利用する
依存パッケージのような変更の少ないファイルに対して使用
アーティファクト：
ワークフローの1回の実行内でファイルを複数のジョブ間で受け渡したり、
ワークフロー完了後に利用するファイルを保存するために使う
バイナリ、アーカイブ、デバッグ用のログ、テスト結果、カバレッジ情報など
引用資料：Github-Actions実践入門
ktGITHUB_SHA・GITHUB_REF
イベント発生時に設定される環境変数
pushイベント
↓
GITHUB_SHA = pushされたコミットのSHAが設定される
pushした時点のブランチ上のワークフロー設定ファイルを元に、
実行されるワークフローが決定される
issue_comment
↓
デフォルトブランチ 最新ブランチのSHA
ktGithub Actions ログによるコマンド実行(echoの活用)
ワークフロー実行中に特定のフォーマットの文字列を出力することで以下のことができる
- 環境変数の設定
- アウトプットの設定
- PATHの追加
- debugメッセージの出力
- warningメッセージの出力
- errorメッセージの出力
- ログのマスク
- コマンド実行の停止・再開
例：
# echo "::<コマンド名> <key><value>,<key><value>::<コマンドバリュー>"
echo "::set-env name=TZ::Asia/NorthEast-1"
引用資料：Github-Actions実践入門
ktGithub Actions セルフホストランナーについて
自分の管理するマシン、VM、コンテナ上でワークフローを実行する
リポジトリ単位、organization単位で追加可能
マネージドランナー：
- 環境が自動更新・運用お任せでOK
- ジョブ実行ごとにクリーンなVMを利用
- プライベートリポジトリだと料金発生
セルフホストランナー：
- 既存のローカルマシン、クラウドサービス上のリソースを利用できる
- 独自要件に合わせてカスタマイズ可能
- 複数のジョブ実行間で環境の持ち越し可能
- プライベートリポジトリで無料
セキュリティ
パブリックリポジトリでセルフホストランナーを利用する事は非推奨
↓
PRでリスクあるコードを実行される恐れがある
引用資料：Github-Actions実践入門
ktアクションについて
種類：対応OS
JavaScript：Linux、macOS、Windows
Dockerコンテナ：Linux
JSの特徴：
- 全てのVM環境から直接実行できる
- Dockerコンテナと比べてイメージのダウンロードやビルド、コンテナの起動コストが発生しない
- ↑の為高速
Dcokerの特徴：
- OSがLinuxのみ
- プロセスが隔離されていていつも同じ環境でアクションを実行できる
- イメージのダウンロード、ビルド、コンテナの起動コストが生じる
- ↑の為速度はJSより遅め
アクションのバージョン指定
commit SHA：actions.setup^node@**SHA**
タグ：actions/setup-node@v*.*.*.
ブランチ：actions/setup-node@master
引用資料：Github-Actions実践入門
ktGithub Actionsのメモ
後で追記
ktactions/cache@v3
ドキュメント：
ktCircle CI APIについて
セキュリティインシデント発生時に活用したドキュメント
ktGithub Actionsでnpmプライベートリポジトリをinstallする
以下でnpm installが成功した
- uses: actions/checkout@v3
with:
persist-credentials: false
- name: Github Apps Token
id: github_access_token
uses: tibdex/github-app-token@v1
with:
app_id: ****
installation_id: ****
private_key: ${{ secrets.KEY }}
- name: Install npm
env:
GITHUB_TOKEN: ${{ steps.github_access_token.outputs.token }}
run: |
git config --global --add url."https://x-access-token:$GITHUB_TOKEN@github.com/".insteadOf "https://github.com/"
npm install
実装で活用した記事：
stack over flow：
参考にした記事メモ
Github Apps経由でtokenを用いてActionsで使う記事：
insteadOfの解説記事：
git configの解説：
詳細解説 (npmではない)
OAuth・Basic認証の解説記事：
PHP privateなリポジトリのPersonal AcessTokenを取得 解説：
HTTP-basedについて
Git Hub Actions入門
ktActions actions/checkoutでのpersist-credentials 設定について
The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.
# Whether to configure the token or SSH key with the local git config
# Default: true
persist-credentials: ''
公式
I propose the persist-credentials feature be removed completely and then v3 be released. Otherwise, if that's not practical, then at least the default should be changed to false.
Just as a heads up for anyone stumbling upon this issue:
①persist-credentials: false is only relevant when you use ssh authentication, because
②GITHUB_TOKEN is always exposed to all jobs, and by default has write access to your repo.
So if you want to harden security, apart from setting persist-credentials: false for ssh auth, make sure that GITHUB_TOKEN auth has no write permission to your repo.
Issue
trueのままだと後続のgitコマンドでデフォルトのアクセストークンが使われるような設定になってしまう。
セキュリティ的にもfalseに設定しておく事が望ましい。
ktGITHUB_TOKEN シークレットトークンについて
自分用整理
GIthubでは、GitHub Actions の代理で認証を受けるために使用できるトークンが提供される
いつ?
↓
各ワークフロー実行の開始時
↓
ワークフローで使用する一意の GITHUB_TOKEN シークレットが自動的に作成される
GITHUB_TOKEN はワークフロー実行での認証に使用可能
Actionsでリポジトリに登録したGitHub Appをインストール
↓
GITHUB_TOKEN シークレットは GitHub App インストール アクセス トークン
↓
インストールアクセストークンは、
リポジトリにインストールされたGitHub Appの代わりに認証を受けるために利用
ジョブが終了するか最大 24 時間後にGITHUB_TOKEN の有効期限が切れる
公式：
ktGithub ActionsのGITHUB_TOKEN permissionsがデフォルトでread-onlyになった
ソース：
ktGithub Actionsのpermissions設定について
参考記事：
ktCircle CIのリポジトリに入れたい環境変数をjsonに記載してシェルからAPIで一括登録する
メモ (大まかなシェルの枠組みはchatGPT経由で出力してもらった)
#!/usr/bin/env bash -ex
# 実行時のログ
LOG=~/circleci_import/import.log
exec &> $LOG
# APIトークン、組織名、プロジェクト名を設定
API_TOKEN="Circle CIのPersonal API Tokens"
ORG_NAME="組織名"
PROJECT_NAME="リポジトリ名"
# JSONファイルのパスを設定
JSON_FILE_PATH="****.json"
# JSONファイルから環境変数を読み込んでCircleCI APIで登録
jq -c '.[]' "${JSON_FILE_PATH}" | while IFS= read -r line; do
VARIABLE_NAME=$(echo "$line" | jq -r '.name')
VARIABLE_VALUE=$(echo "$line" | jq -r '.value')
curl -s --request POST \
--url https://circleci.com/api/v2/project/github/${ORG_NAME}/${PROJECT_NAME}/envvar \
--header "Circle-Token: ${API_TOKEN}" \
--header 'content-type: application/json' \
--data "{\"name\":\"${VARIABLE_NAME}\", \"value\":\"${VARIABLE_VALUE}\"}"
done
※注意点
パーソナルアクセストークンは以下の形で読み込ませる
--header "Circle-Token: ${API_TOKEN}"
公式の例には記載されてない為、見落としていた。。
ktGithub Actions repository_despatch, workflow_dispatchについて
参考記事：