これらを1個1個 curl などを使ってインストールするコードを書くのは面倒ですが、
aqua であれば設定ファイルを宣言的に書いて aqua i を実行すれば終わりです。
新たにツールを追加する場合でも設定ファイルに追記すればよく、スクリプトを更新する必要はありません。
バージョンを明示的に指定できるのでコードを変更してないのに急にツールが更新されることもありませんし、 Renovate の Regex Manager などを使えば更新を自動化することもできます。
The only signal values guaranteed to be present in the os package on all systems are os.Interrupt (send the process an interrupt) and os.Kill (force the process to exit).
On Windows, sending os.Interrupt to a process with os.Process.Signal is not implemented;
it will return an error instead of sending a signal.
Platform Engineer / OSS Developer / Go / Terraform
In this post I introduce how to split a huge .circleci/config.yml.
CircleCI doesn't support to split .circleci/config.yml, so we manage all workflows and jobs configuration into one file .circleci/config.yml.
If the repository is Monorepo, the more the number of services increases, the more the size of .circleci/config.yml becomes large and it's hard to maintain .circleci/config.yml.
By splitting .circleci/config.yml per service, it makes easy to maintain .circleci/config.yml and we can configure split file's CODEOWNERS.
To split .circleci/config.yml, you have to generate .circleci/config.yml by merging split files and commit both split files and .circleci/config.yml.
We can merge split files with the command circleci config pack, but I introduce the other tool circleci-config-merge.
CircleCI CLI is an official tool so it's reliable, but I feel the restriction of the file name and the directory structure is a little strict.
We have to manage all files on the same directory, and the file path is reflected to generated YAML content.
For the detail of circleci config pack, please see the official document.
If you can accept the restriction of circleci config pack, I recommend to use it because it is an official tool.
But if it is difficult to accept the restriction, maybe circleci-config-merge would help you.
If you split .circleci/config.yml, you should test in CI whether .circleci/config.yml is generated by merging split files.
circleci-config-merge doesn't provide such a feature, but you can implement the test with the other tool like dyff.
Lastly, I introduce a use case of circleci-config-merge.
Recently, I split a huge .circleci/config.yml which is over 6,000 lines to about 60 files.
It was hard to maintain the original .circleci/config.yml, but by splitting it became easy to maintain .circleci/config.yml.
If you are suffer from a huge .circleci/config.yml, let's split it!
In this post I introduced how to split a huge .circleci/config.yml.
We can generate .circleci/config.yml by merging split files with circleci-config-merge.
Please see the example suzuki-shunsuke/example-circleci-config-merge as a reference to split .circleci/config.yml and setup CI.
モチベーションは、 PR をマージしたあとに CI がこけた場合に通知が欲しいというものです。
マージしたあとに CI が一瞬で終わるなら無事終わるのを見届けてもいいんですが、
数分かかると待ってるのも時間がもったいないです。
しばらくしたあとに結果を確認すればいいんですが、それも面倒くさいですし、普通に忘れます。
そうするとデプロイしたつもりが実は CI がこけてたなんてことが普通にあります。
タスクが依存するファイルパスの条件 は独自のフォーマットで指定します。
gitignore のフォーマットにインスパイアされていますが、正規表現が使えるなど、独自のフォーマットになっています。
CI の中でシェルスクリプトで動的に生成することを想定し、行指向のフォーマットになっています。
Go 実装のパーサーが提供されたよく知られた行指向の(コマンドで生成しやすい)フォーマットがあれば良かったんですが、見つからなかったので簡単にフォーマットを定義してみました。
シェルスクリプトで複雑な CI を実装していると、メンテナンス性が悪くなります。
チームメンバーのシェルスクリプトへの習熟度に依存しますが、
シェルスクリプトはエンジニアなら誰でも書ける分全員が習熟しているとは限りませんし、
容易にバグが生まれます。
チームによりますが、Python や Ruby, Go といった他の言語と比べ、 lint や test がされてないことが多いせいもあるとは思います。
アプリケーションのコードは当然 CI で test, lint するのに、
CI とかのシェルスクリプトはしないというのも珍しくないと思います。
If you are writing a script that is more than 100 lines long, or that uses non-straightforward control flow logic, you should rewrite it in a more structured language now
