変数の保護について修正しましたpush時にphp-cs-fixerをかけて、修正箇所があれば自動コミットする方法です。大まかな処理内容feature/*ブランチまたはfix/*ブランチに対して処理する。masterに対しては行わない。-l仕掛けとしては、カレントディレクトリに対象コミットがチェックアウトされた状態でdockerが起動されているので、これを変更してpushしてしまうというものです。記載されているものがベースです。noはやりすぎかもしれません。中に書いてある環境変数CI_COMMIT_REF_NAMEは自動でセットされるもので、この場合ではブランチ名です。GIT_SSH_PRIVATE_KEYは自分で設定する変数で、設定画面で秘密鍵を設定しておきます。この鍵を使って自動修正をリポジトリにpushします。gitlabでの設定まず、パイプライン実行時に渡す変数を設定します。次に公開鍵を設定します。ユーザに紐付けると統計情報に影響があるため、デプロイキーとして設定します。デプロイキーは書き込み権限ありで設定します。これでリポジトリにpushする準備ができました。ブランチを切ってpushする上記の.gitlab-ci.ymlと、php-cs-fixerに修正されるようなソースをcommit/pushします。次のようなコードを書きました。'tough'];}開きカッコの位置が修正対象で、これはpsr-2では「改行してから開く」ということになっています。パイプラインは2つ実行されました。失敗しているのがphp-cs-fixerによる修正、直後に実行されているのがその修正コミットによるものです。コミットログはこんなかんじです。1つまえのmasterブランチに対する実行は1つしかありませんが、.gitlab-ci.ymlに書いたonlyの指定によりcs-fixerジョブが対象外となり、php-lintジョブだけが実行されたものです。自動コミットの方法は今後変わるはずどこか忘れましたが、gitlab.comのどこかに「gitlab-ci上での自動コミットのサポート」というissuesがあったはずです。ここで行っている処理は多少強引なので、正式にサポートされたならそれに追従したほうが素直な書き方になるでしょう。公開時は「秘密鍵の変数を保護、合わせてfeature,fixブランチも保護」と書いていましたが、コメントがあり変数を保護しないように修正しました。ご指摘ありがとうございました。興味深い記事を執筆して頂きありがとうございます。「保護ブランチ」について、使用方法に誤りがあるので修正したほうが良いと思います。“feature/*”を「保護ブランチ」にすると、ブランチの削除ができなくなるで通常は行わない方が良いです。「保護ブランチ」にしてもスクリプトから保護した変数を読み取ることができるので、今回のケースではセキュリティを向上させる効果もほとんどありません。保護した変数のユースケースとしては、プロダクション環境のデプロイキーをMaintainer権限のユーザーのみに公開し、Developer権限のユーザーには秘匿したい場合などがあります。23:29の上コメントありがとうございます。記事を書いた動機がclosedプロジェクトに対してだったので「とりあえず保護しとこう」で進めましたが、openなプロジェクトだとご指摘の通り誤りになってよろしくないですね。.gitlab-ci.ymlで秘密鍵をechoするコードをfeatureブランチにpushしてしまえばログに出てしまうのに、保護されていると勘違いしそうです。これから記事を修正します。変数保護しないように修正、合わせてブランチ保護のくだりを削除しました。ご指摘ありがとうございました。コメントをキャンセルメールアドレスが公開されることはありません。