precompiled groovy dsl は buildSrc プロジェクトに gradle ファイルを入れておくと、メインの build.gradle でプラグイン取り込みの仕組みを使って取り込める機能で、ファイルを分割して apply from <file> としてたビルドファイルを分割していた仕組みの強化版(コンパイルされるので速い)です。
sdkman で複数のバージョンの Java をディレクトリーごとに切り替える
複数のプロジェクトを行ったり来たりする際に、プロジェクトごとに Java のバージョンが違っている際は、たいてい IntelliJ が覚えていてくれるので、それほど困ってはいないのですが、世の中にはターミナルでなんでもこなす人がいるらしく、プロジェクトごとに Java のバージョンを設定するツールが求められているらしいです。いわゆる env 系ツール(renv 、 nodenv)ですが、それの Java 版の jenv というものがあるようです。
ざっとドキュメントを見たところでは「特定のディレクトリのみこのバージョンを使う」という設定ができるかどうかわかりませんでした。
ということのようですが、つい先程、 sdkman でもそのようなニーズに答えるようになったようです。
SDKMAN 5.8.1 is rolling out, featuring the new `sdk env` command for switching SDKs per project. Thanks to @helpermethod for his contribution! https://t.co/ZEQaFx6bpD
— SDKMAN! (@sdkman_) 2020年5月4日
というわけで、 バージョン 5.8.1 から使える env の動作を確認してみようと思ったのですが
このブログを書いている時点ではまだ更新できませんでしたが、すでに env コマンドが搭載されているようなので試してみることにしました。
github actions で GraalVM でつくったネイティブアプリケーションを GitHub リリースする
date コマンドを使うときにいつもググって調べるくらいの unix 音痴で、 Java の JSR310 ならすぐできるのにと思うことが多いので、そのようなコマンドを作ることにしました。
機能はまだ作り込んでいなくて、まずはフォーマットを指定できるだけです。
対応 OS は Linux と Mac OS X です。 Windows でも Windows SDK 7.1 の環境を整えればビルドできます(参考は こちら)が、 github actions で環境を整えるのが難しそうだったので、github ではリリースしていません。
なお、Mac OS X 版はサインしてない野良アプリなので、初回の起動は「Mac 野良アプリ 起動」でググったら出てくる Apple の未署名のアプリの起動方法みたいなページを参考に起動してください。
本題に戻ると、公式の actions を使いこなせばそれほど難しいところはありませんでした。
github actions のワークフロー概略は次の図のとおりです。
ポイントとしては、
- タグに付き一つしかリリースを作れないので、
create-releaseは最初の Job で実行する create-releaseをしたときの結果であるrelease_id(未使用) とrelease_urlを artifact として upload する- 各 OS の job では、最初の Job の artifact である
release_urlをダウンロードしてビルドしたバイナリーをupload-releaseでリリースする
です。
Golang のように、一つの OS ですべてのバイナリーをビルドできないので若干手が込んでいます。
また、 GrallVM のセットアップには DeLaGuardo/setup-graalvm@2.0 を使っています。これは比較的高速にセットアップされるのでこれと Gradle graalvm-native-image プラグインを使うと native-imageを作るときにに GraalVM をダウンロードする仕組みよりも高速にビルドできます。
