Windows の場合、インストーラー、またはzipファイルをダウンロードします。
インストーラーからインストールする場合は、手順に従ってインストールしてください。
zipファイルをダウンロードし、解凍すると実行ファイルが含まれています。
実行ファイルを適切な場所に移動すると良いと思います。
Mac の場合、必要に応じてAppにコピーします。

JDK のインストール

JDKをダウンロードし、開発環境から使用できるように準備が必要です。

Java は複数の組織がバイナリを提供しているため、提供元が複数存在します。

Java は互換性があるため、多くの場合では違いを意識する必要はありません、

環境毎で指定のJDKがあれば、指定のものをダウンロードして利用してください。

特に指定やこだわりがなければ Oracle、もしくは Adoptium あたりを使われる場合が多い印象があります。

SDKMAN を用いたインストール

SDKMAN を用いてJDKのインストールすることが可能です。

Windows 以外であればこの方法が一番おすすめです。

ディストリビューションの一覧やダウンロードまで実施できますし、

利用に必要な設定や管理も行えます。

SDKMANのインストール方法・使用方法は以下を参考にしてください。

SDKMAN インストール方法

SDKMAN を用いたJDKのインストールの例を以下に示します（java.net OpenJDK 18 の場合）。

sdk install java 18.0.1.1-open

実行すると、以下のような出力がされ、インストールが実行されていきます。

Downloading: java 18.0.1.1-open

In progress...

################################################################################################################### 100.0%

Repackaging Java 18.0.1.1-open...

Done repackaging...
Cleaning up residual files...

Installing: java 18.0.1.1-open
Done installing!

Do you want java 18.0.1.1-open to be set as default? (Y/n): Y

Setting java 18.0.1.1-open as default.

Java Extension Pack の Getting Start の機能からダウンロードする

後述する「Java Extension Pack」インストール後であれば、Visual Studio Code 上の操作から JDK をダウンロードすることが可能です。

Java Extension Pack の「Get Start with Java Development」の機能からもJDKをインストールすることができます。

Visuial Code Studio を開き、「Help」->「Get Start」を選択します。

「Walkthroughs」の「More...」をクリックし、「Open Walkthroughs...」という検索ボックスが出るので「Get STarted with Java Development」を入力し実行する。

「Get STarted with Java Development」の画面に遷移するので、「Get your runtime ready」という項目から「Install JDK」をクリックします。

「Install New JDK」という画面が表示されるので、必要なJDKをインストールすることができます。

各JDK ディストリビューションのダウンロードサイトから取得する

各JDKのディストリビューションのダウンロードサイトから取得する方法があります。

何箇所かのディストリビューションとダウンロード先は以下になります。

Visual Studio Code の設定

拡張パックの追加

Javaの開発で必要となる拡張パックをインストールします。

必要となる主な拡張パックは以下になります。

拡張パック名	パッケージURL	概要
Extension Pack for Java	https://marketplace.visualstudio.com/items?itemName=vscjava.vscode-java-pack	Java の開発用拡張パックです。 Javaのコード補完、ビルド、GUIからのJUnit（ユニットテスト）実行などが可能になります。
Spring Boot Extension Pack	https://marketplace.visualstudio.com/items?itemName=Pivotal.vscode-boot-dev-pack	SpringBoot 開発用拡張パックです。 SpringBoot由来のアノテーションの解決や機能と参照できるようになります。 SpringBootを使用しない開発では不要です。
Lombok Annotations Support for VS Code	https://marketplace.visualstudio.com/items?itemName=GabrielBB.vscode-lombok	Lombok 用の拡張パックです。 `@Getter`, `@Setter`, `@Slf4j`などのLombok由来のアノテーションの解決ができるようになります。 Lombokを使用しない開発では不要です。

Java用の設定追加

設定ファイルにJavaを実行するための設定を追加します。

setting.json にJDKへのパスを指定する java.jdt.ls.home を設定します²。

{
  "java.jdt.ls": "/Users/<user_name>/.sdkman/candidates/java/current/"
}

<user_name> は環境に応じて読み替えてください。

java.home のパス自体も環境に応じて変更してください。

settings.json を表示させる方法は設定画面から、右上の方にある「Open Settings」の画像をクリックして表示することができます

設定画面の出し方は以下のいずれか

OS	画面での操作	ショートカットキー
Mac	「Code」-> 「Preferences」->「Settings」	「Command」+「,」
Windows	「File」-> 「Preferences」->「Settings」	「Ctrl」+「,」

設定の完了

以上で設定は完了です。

開発が必要なレポジトリーを使って確認してみてください。

開発対象のレポジトリーがない、Javaプロジェクトの作成方法がピンとこない。という方がいましたら、

動作確認用に以下のレポジトリーを用意しましたので、お試しください。

Java-Gradle の動作練習用レポジトリ

ご参考までに。

最後に

結び

Visual Studio Code でJavaの開発ができるようになりました。

開発ツール自体の初期設定やJDKのダウンロードなどが必要でしたが、

手順を進めれば開発環境が作れることが実証できました。

参考

Visual Studio java-tutorial

IntelliJ IDEA のインストール、設定方法。および使い方が気になる方はプロになるJava を参考にしてみてください↩
古いバージョンだと “java.home” になりますが、現行（2022年6月時点）では非推奨になっています。↩

2022-05-08

Intellij IDEA の GUI から force push したい

JetBrain IDE から remote branch に対して force push をするための方法について
git push -f 相当をしたい場合です。
どこかに書くほどではないのですが、最初わからず彷徨っていたので備忘録も兼ねて記載します。

環境については以下

MacBook Air（M1 2020）
IntelliJ IDEA 2022.1 (Ultimate Edition)

以下の記事で設定変更をする方法が説明されているのですが、現行（2022現在）では設定変更は不要です。

IntelliJ の GUI から git push -f したい - Qiita

local branch でamend commit や rebaseを行った際、
remote branch と差が出てしまい、デフォルトの設定のままでは push しても失敗します。

※２種類の矢印で差分があることがわかる。rebase や merge をして push しても、reject される。

この対処方法として、コマンドラインから Git を使う場合は、git push -f で強制 Push する方法がありますが、
JetBrain IDE では Push するときに「Force Push」を選択して実行することが可能です。

Commnad + Shift + K で Push ダイアログを表示。
「Push」ボタンの右下のプルダウンから「Force Push」を選択し、強制Pushを行うことが可能。

追記:

masterへの force push はデフォルト設定では無効になっています。

もし master へ force push したい場合は設定変更が必要になります。

（業務ではほぼないと思いますが）

[Preference]から設定ダイアログを開き、[Version Controle]->[Git]で設定。

[Push] の[Protected branches]の設定を変更。

保護するブランチ名を変更、もしくは空白にします。

2022-05-02

「良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方」を読みました

はじめに

技術書を読みました。読んだのは以下の本、「良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方」です。

良いコード／悪いコードで学ぶ設計入門―保守しやすい　成長し続けるコードの書き方

作者:仙塲大也
技術評論社

Amazon

設計について有名なミノ駆動さんが書かれた本ということで発売前から注目度の高かった本なので、ご存知の方も多いと思います。逆張り思考の私としては「読んでなるものか」と思っていたのに、誘惑には勝てず購入をしてしまい、読んだ後には充実感を得るほどの満足できる内容の本だったため、ブログに記載してみようと思いました。

該当書籍を読んでみて

もう少し

まず、かなり「読みやすかった」というのが第一印象です。構成がしっかりされていて、課題の説明から入り、解決方法について、解説という流れが全体にあるので、納得しながら読み進められました印象です。表現も理解しやすいもので説明されている印象だったため、解釈がとてもわかりやすかった印象です。

内容で説明されているリファクタリングテクニックもかなり具体的かつ実用的なものが多いと感じました。悪い設計・実装例について、例文がソースコードとして載っていますし、問題点だけでなく、しっかりその対応方法についても説明されているのがとても好印象を受けました。どういう風に当てはめれば良いか、という点についても前述した課題の説明からされているので、想像しやすいと思います。

この手の本や資料は「課題だけ」や「テクニックだけ」となるものも少なくない印象ですが、両方説明されているのが良いと感じました。「理想像をイメージする大切さ」について、著者が取り組んできた空手の経験から説明もされていましたので、そういった部分を意識し、意図した内容になっているのかなと想像しています。

発売記念勉強会¹で話されていた時、「プログラムの入門を終え、設計の専門書に挑む前に読むエントリー本のイメージ」という旨の発言をされていたと記憶しているのですが、まさにその表現の通りの内容になっていると感じました。

一度設計について学んだ人でも、再確認や復習として、とても参考になるのではないかと思います。

さらに勉強を進めたい人用に参考書籍の紹介や取り組み方も最終章に記載されているので、どこまでもフォローが行き届いているという充実ぶりでした。

『良いコード/悪いコードで学ぶ設計入門』著者トーク - connpass ↩

2022-05-01

M1 Macと docker compose の付き合い方について考えた

はじめに

背景

Mac Book Air 2020 年モデル、いわゆるM1 Macを買いました。今まで使っていた Dockerを動かすとき、docker composeの使い方が変わったので、その内容について記載します。

まえがき

CPUが Apple Silicon と呼ばれるもので、ARMプロセッサーのCPUになります。以前までのIntell製のCPUと違う点がよく挙げられるのですが、ソフトウェア開発者視点で遭遇するものの一つにDockerがあります。

今までIntel製で動いていたDockerファイルが動かない。と言われたり、実際になったりすることがあります。というか、なりました。

M1 mac の Docker、アーキテクチャが違って起動できない場合はちゃんと表示してくれるんだな pic.twitter.com/gKDkf6XxI5
— 名前迷子 (@maigo_name) 2022年4月30日

その時の Docker、docker compose の使い方についてをまとめようと思います。

環境

今回試した環境は以下 - OS: macOS Monterey - CPU: AppleM1 - メモリ: 16GB

方法

具体的な対応方法について、知っている範囲で説明を記載していこうかと思います。

ARM CPU 対応版の Docker ファイルを利用する

既存のDockerファイルがあり、コミュニティの方でDockerファイルを管理されている場合、 ARM CPU 対応されたイメージがある場合があります。

cassandra を例にすると、Intel CPU で動く cassandra、 ARM 対応した arm64v8/cassandra があります。そういった対応版を使うとよさそうです。

その他：アーキテクチャを指定する

Docker の起動時、プラットフォームを指定する方法です。マルチ CPU アーキテクチャのサポートを活用 — Docker-docs-ja 19.03 ドキュメント

1年ほど前（2021年）の時点では、mysql などはM1 Mac で起動すると起動が失敗するケースがあったようです。（いま手元で試したら mysql は起動したので、Docker側で対応されている気がする）

その際は docker で起動した時にアーキテクチャ指定を行うことで起動していました。起動時のオプションに--platform linux/x86_64を指定します。

docker compose について

Intel CPU、arm CPU が混在する環境、チームではどうすると良いかと考えた時について。個人的な解決しては「docker composeファイルの差分ファイルを作って、読み込むようにする」という結論に落ち着きました。

docker-compose.yaml は複数指定すると、差分を上書きして実行してくれます。

ファイル間、プロジェクト間での Compose 設定の共有 — Docker-docs-ja 19.03 ドキュメント

これを利用して、開発者ごとに差分を読み込むようにします。

共通の docker compose ファイル。docker-compose.yamlとする。

version: '3'
services:
  sandbox-service:
    build:
      context: .
      dockerfile: ./Dockerfile
    tty: true
    volumes:
      - ../:/app
    working_dir: /app
    ports:
      - 8080:8080
  cassandra:
    image: cassandra:4.0
    tty: true
    ports:
      - 9042:9042

差分の docker compose ファイル。m1mac.yamlとする。

version: '3'
services:
  cassandra:
    image: arm64v8/cassandra:4.0

それぞれの環境ごとでコマンド実行時に読み込みを行います。

Intel CPU ユーザー

docker compose -f docker-compose.yaml up -d

ARM CPU ユーザー

docker compose -f docker-compose.yaml -f m1mac.yaml up -d

アーキテクチャ指定で起動する場合でも、docker-compose ファイル、環境差分ファイルにも起動オプションに上記を指定すれば問題ないのかなと思います。

終わりに

無事にM1Mac でも Docker、docker composeが使える目処がたちました。まだ触れ出したばかりなので、色々試していきたいと思います。

2021-12-15

SpringBoot/Gradleのlogback脆弱性更新したときの方法

はじめに

log4j2 の脆弱性が2021年12月10日に報告され、

任意のプログラムを実行できる危険性があるため、早急に対応することが必要という事で話題になりました。

logback にも「同じ脆弱性の懸念がある」という報告が12月14日におこなわれました。

https://jira.qos.ch/plugins/servlet/mobile#issue/LOGBACK-1591

これらの脆弱性の対応方法はライブラリのバージョンアップすることになります。

log4j2, logback の更新を自分のレポジトリーで行ったので、実績として残しています。

脆弱性バージョン更新の対応

log4j 2 の脆弱性対応について

私の関係しているものでは log4j2（log4j-core）をログ出力の実装ライブラリとしてつかっているのはなかったのですが、

slf4j は使っていたので、log4j2-api は依存として含まれていました。

脆弱性の原因とされていた JNDI lookup 機能は log4j-core で使われているので、関係ないのですが、

影響度が大きさと、あげない理由もなかったので対応しておこうと思いました。

その時に参考にさせていただいたブログは以下になります。

https://irof.hateblo.jp/entry/2021/12/10/180215

自分は SpringBoot/Gradle/io.spring.dependency-management plugin の構成だったので、

上で参考にさせていただいたブログのとおり、以下の記述を build.gradle に設定することで対策できました。

ext['log4j2.version'] = '2.15.0'

※ブログ記載現時点で lookup 機能自体が削除された 2.16.0 がリリースされているので、そちらを使うのが良いと思います。

補足

この方法が良いと思ったのは、関連する log4j 2 のライブラリバージョンをまとめてバージョンアップできるためです

dependencies で個別のライブラリのバージョンを更新しても対象のライブラリの更新は可能ですが、

他にも log4j 2 関連の依存ライブラリが含まれていて、更新しておけばよかったとか、

log4j 2 のバージョンが異なって食い合わせが良くないとが発生するのが気になるところが懸念としてありました。

※バージョン違いによる懸念は参考にさせてもらったブログにも書かれていましたね。IFやシグネチャの変更などが理由。

logback の脆弱性対応

12月14日時点ですでに対応版の 1.2.8 がリリースされているので対応しました。

log4j 2 と同様にgradle の ext に logback のバージョンを指定することでバージョン更新可能です。

build.gradle

ext['logback.version'] = '1.2.8'

アップデートの確認。依存する logback が 1.2.8 に更新されているのが確認できる

> .\gradlew dependencies |findstr logback
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8

追伸

build.gradle の dependencies にライブラリを直接している場合は注意した方がよさそうです。

そちらにバージョン指定していた場合、そちらが優先されるため。

dependencies {
    // log
    implementation "ch.qos.logback:logback-core:1.2.7"
}

> .\gradlew dependencies |findstr logback
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7
+--- ch.qos.logback:logback-core:1.2.7
+--- ch.qos.logback:logback-core:1.2.7 (n)
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7
+--- ch.qos.logback:logback-core:1.2.7
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7
+--- ch.qos.logback:logback-core:1.2.7
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7
+--- ch.qos.logback:logback-core:1.2.7
|    |    |    +--- ch.qos.logback:logback-classic:1.2.7 -> 1.2.8
|    |    |    |    +--- ch.qos.logback:logback-core:1.2.8 -> 1.2.7
+--- ch.qos.logback:logback-core:1.2.7

最後に

迅速な対応をいただいたライブラリメンテナーの皆様、情報共有をいただけた皆様にまことに感謝いたします。

2021-12-07

Java /Gradle shadow プラグインの力で fat Jar を簡単に作る

はじめに
- 動機
- 環境
fat Jar について
fat Jar を作る選択肢
Gradlew にshadow プラグインを使う
最後に

はじめに

動機

今はあまりなくなってしまいましたが、Java のプログラムを fat Jar として作って頒布する機会があったので、その時に試した方法について記載します。

Java は長期的に動くサーバーサイドの開発などに使うことが多いと思うので、そういうケースは少ないと思いますが、

Java の資産を使ったモジュールを作ったり、古いソフトウェアのメンテナンスなんかでそういうユースケースがあるという認識です。

Gradle の shadow plugin*1 を使えば簡単に fat Jar を作れました。

環境

今回、私の実行するために利用した環境は以下になります

Windows 10 Pro
openjdk-17
Gradle 7.2
IntelliJ IDEA Ultimate (2021.2.3)

fat Jar について

fat Jar とは依存関係含む、すべての class を含んだ jar ファイルのことです。

plugins {
    id 'java'
}

group 'com.github.keyno63'
version '1.0-SNAPSHOT'

repositories {
    mavenCentral()
}

dependencies {
    implementation 'com.fasterxml.jackson.core:jackson-databind:2.13.0'
}


// jar 実行の manifest の設定
jar {
    manifest {
        attributes "Main-Class": "com.github.keyno63.app.Main"
    }
}

例えば、Jackson を使ってコマンドラインから渡した Json 文字列を分解するような、

以下のようなプログラムがあったとします。

package com.github.keyno63.app;

import ...;

public class Main {
    public static void main(String[] args) throws JsonProcessingException {
        final List<String> argsList = Arrays.asList(args);
        if (argsList.size() > 0) {
            ObjectMapper mapper = new ObjectMapper();
            final JsonData json = mapper.readValue(argsList.get(0), JsonData.class);
            System.out.println(json);
        }
    }


    public static class JsonData {
        private final String value;

        @JsonCreator
        public JsonData(@JsonProperty("json_key") String value) {
            this.value = value;
        }

        @Override
        public String toString() {
            return String.format("""
                {
                  "json_key": "%s"
                }
                """, value);
        }
    }
}

単純にビルドして実行すると以下のように失敗するかと思います。

> .\gradlew clean build

BUILD SUCCESSFUL in 1s
3 actionable tasks: 3 executed
> java -classpath ".\build\libs\gradle-shadow-1.0-SNAPSHOT.jar" com.github.keyno63.app.Main '{\"json_key\": \"json_value\"}'

エラー: メイン・クラスcom.github.keyno63.app.Mainを初期化できません
原因: java.lang.NoClassDefFoundError: com/fasterxml/jackson/core/JsonProcessingException

依存関係の com.fasterxml.jacksonが生成した jar に含まれていないので、実行時に依存関係が解決されずに失敗します。

実行するためには依存関係のある jar への classpath を通すと実行することもできます。

> java -classpath "<jackson の jar への path>;.\build\libs\gradle-shadow-1.0-SNAPSHOT.jar" com.github.keyno63.app.Main '{\"json_key\": \"json_value\"}'
{
  "json_key": "json_value"
}

それでも動くのですが、頒布する場合とかに利用してもらう人に依存関係の jar ファイルを用意してもらうのもハードルが高いので、fat Jar を作ることにしました。

fat Jar にすれば、依存関係をすべて含むその jar のみで完結して実行することができます。

> java -jar .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar '{\"json_key\":\"json_value\"}'
{
  "json_key": "json_value"
}

fat Jar を作る選択肢

fat Jar を作る他の選択肢としてあがるのは以下になるかと思います。

build.gradle 設定を変更して作る*2
gradle-fatjar-pluginを使う*3
gradle shadow plugin を使う

build.gradle 設定を変更する方法は複雑かつややこしいように感じたので、できれば自動化に近い仕組みを使いたかったので選択肢から外れました。

gradle-fatjar は 2015 年以降更新されていないので、選択肢から外れました。

以上の理由から shadow プラグインを使うようしました。

Gradlew にshadow プラグインを使う

すること

対応することは以下の2点です。

plugin に shadow を追加する
gradle shadow コマンドでfatJar を作る

build.gradle の編集

build.gradle にすることは plugins に shadows を追加するだけです。

plugins {
    id 'java'
    id 'com.github.johnrengelman.shadow' version '7.1.0' // 追加
}

jar をそのまま実行できるように manifest の設定を追加しておくのもお勧めです。

// jar 実行の manifest の設定
jar {
    manifest {
        attributes "Main-Class": "com.github.keyno63.app.Main"
    }
}

fat Jar 生成

あとはターミナル、およびIDEのコマンドから gradle shadowJar相当を実行します。

デフォルト設定のままであれば .\build\libs配下に実行用の jar ができています。今回であれば gradle-shadow-1.0-SNAPSHOT-all.jar というのができています。

> .\gradlew clean shadowJar
> dir .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar

jar の中身をみると、依存関係のパッケージのクラスも含まれているのがわかります。

> jar tf .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar
META-INF/
META-INF/MANIFEST.MF
com/
com/github/
com/github/keyno63/
com/github/keyno63/app/
com/github/keyno63/app/Main$JsonData.class
com/github/keyno63/app/Main.class
META-INF/LICENSE
META-INF/maven/
META-INF/maven/com.fasterxml.jackson.core/
:

動作確認

生成した jar を指定して、実行可能なのが確認できます。

> java -jar .\build\libs\gradle-shadow-1.0-SNAPSHOT-all.jar '{\"json_key\": \"json_value\"}'
{
  "json_key": "json_value"
}

以上で無事やりたいことが達成できました。

最後に

かなり簡単に目的を達成できる方法だと感じました。

追加の設定も特に不要なのがありがたいですね。

*1:https://github.com/johnrengelman/shadow

*2:https://stackoverflow.com/questions/4871656/using-gradle-to-build-a-jar-with-dependencies

*3:https://github.com/musketyr/gradle-fatjar-plugin

2021-11-28

scala-steward を個人レポジトリの GitHub Actions で動作させられた記録

はじめに
- scala-steward とは
- モチベーション
  - なぜ scala-steward か
  - GitHub Actions で動かす理由
設定方法
うまくいかなかったこととか、補足とか
- うまくいかなかったこと
- 補足
参考情報
最後に

はじめに

scala-steward を GitHub Actions から実行し、

自分のレポジトリに対してライブラリ更新ができるようにできたので、

その時の内容を記載します。

設定方法がよくわからなかったり、設定項目が何が必要かがわかりにくかったりしたので

それについても残しておきたかった所存です。

作った scala-steward を使うための GitHub Actions の設定レポジトリは以下です

github.com

scala-steward とは

Scala プロジェクトが依存するライブラリがバージョンアップリリースが存在していると、更新するためのPRを自動生成してくれるシステムです。

対抗というか、類似のツールでは Renovate や dependabot などがあります。

モチベーション

なぜ scala-steward か

他にもコンペのツールがある中で scala-steward を使ったかというと、大きくは以下の2点です。

他言語での開発している自前レポジトリでは Renovate, dependabot を使っているので scala-steward をつかってみたかった
多くの有名Scalaプロジェクトで使われているので興味があった

以下の記事によると、Renovate でも結構いけるらしいのですが、

tarao.hatenablog.com

やっぱり scala-steward を使ってみたかったので自分の環境下で動かせるようにしました。

GitHub Actions で動かす理由

実はわざわざ自分で実行環境を用意しないでも scala-steward を使う方法があります*1。

scala-steward の公式が動作する環境を用意してくれていて、

対象レポジトリ一覧に自分の管理するScalaプロジェクトのリポジトリを追加すれば動かすことが可能です

repos/repos-github.md at main · scala-steward-org/repos · GitHub

この方法のネックとしては「更新リクエストを送ってマージしてもらう必要がある」、「自分の作業用レポジトリを追加してもらうのが恥ずかしい」というのがあります。

なので自分で気兼ねなく使える環境が欲しかったため、GitHub Actions での環境を用意しました。

GitHub Actions を使う場合は以下のテンプレートを使わせてもらいます。

github.com

設定方法

前提条件

今回は以下の環境で設定することを前提になっています

scala-steward を実行する専用のレポジトリから動作させます
GitHub App からコミット、PR生成してもらうようにします

設定に必要なこと

設定に必要な作業は以下

GitHub App を生成します
GitHub App の秘密鍵を生成します
scala-steward 実行する専用のレポジトリを GitHub に作成します
レポジトリの設定の secrets に以下の登録します
- 作ったGitHub App から生成した秘密鍵
GitHub Actions の workflow を作成します
scala-steward の実行対象のレポジトリを決定する設定ファイルの作成
GitHub Actions のジョブを有効化します

設定手順

GitHub App を生成

GitHub App の生成するページから「New GitHub App」のボタンをクリックして、

今回使うようの App を作成します。

設定した項目は以下にしてました

GitHub App name
- 好きな名前でいいです。今回は「keyno63-scala-steward」とかにしました。
Homepage URL
- 自分の GitHub アカウントのURLを入れてました
Webhook
- デフォルトでは有効でしたが、今回いらないと思ったのでチェックボックスを外して無効化しました
Repository permissions
- 「Contents」、「Pull Request」を「Read＆Write」にします
そのほかはデフォルトです。

以上の設定をして、「Create GitHub App」をクリックすると、Appが生成されます。

以下のようになっていれば問題ありません*2。

f:id:keyno63:20211128040249p:plain

GitHub App の秘密鍵を生成

App 作成したら、作った App の「Edit」をクリックするか、

https://github.com/settings/apps/<作成したアプリケーション> にアクセスして、

App の編集画面に遷移します。

画面下のほうまでスクロールして、「Private Keys」という項目まで移動します。

「Generate a private key」をクリックして秘密鍵を生成します。

秘密鍵を生成出来たら、.pem ファイルが自動でダウンロードされます。

後で使うのでおいておいてください。

scala-steward 実行用レポジトリを生成

GitHub から新規レポジトリを作成します。

https://github.com/new

ここで作るのは空レポジトリで問題ありません。

必要なファイルは .github/workflows/***.yamlだけです。これはあとで作るので今は何もなしでもよいです。

secret の設定

レポジトリの設定から secretを設定します。

先ほど作成したレポジトリの「Settings」、左メニューの「Secrets」をクリックして遷移します。

「New repository secret」ボタンをクリックして Secret生成画面に遷移します。

f:id:keyno63:20211128042815p:plain

もしくはhttps://github.com/<GitHubアカウント名>/<作成したレポジトリ名>/settings/secrets/actions/newにアクセスしてもらっても大丈夫です。

Nameに後で使う設定名を、Valueには先ほど設定した GitHub App の秘密鍵の中身をコピーして貼り付けてください

自分は「SS_PRIVATE_KEY」という設定名で作成したので以下のようになりました。

同じように Secretが作成されていれば問題ありません。

f:id:keyno63:20211128043548p:plain

GitHub Workflows の作成

GitHub Workflows を作成します。GitHub Actions 用の yaml ファイルを作成します。

以下のように作成して貰えれば大丈夫です*3。

name: CI
on:
  schedule:
    - cron: '0 0 * * 0'
  pull_request:
  push:
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Generate token
        id: generate-token
        uses: tibdex/github-app-token@v1
        with:
          app_id: <作成した app id>
          private_key: ${{ secrets.SS_PRIVATE_KEY }}
      - name: Launch Scala Steward
        uses: scala-steward-org/scala-steward-action@v2
        with:
          github-token: ${{ steps.generate-token.outputs.token }}
          author-name: "<作成した App 名>[bot]"
          author-email: "<作成した App の user id>+<作成した App 名>[bot]@users.noreply.github.com"
          repos-file: 'repos.md'

実例は以下

https://github.com/keyno63/scala-steward-mine/blob/2e31af53b972ef50f2393616b855a4e1dddf66ba/.github/workflows/ci.yaml

補足：app id について

作成した GitHub App の App ID のことです。

GitHub App の編集画面から確認できます。

f:id:keyno63:20211128044649p:plain

補足：author-email の取得

GitHub App のユーザー情報取得するAPIから、user id を取得できれば、App用の email が取得できます。

https://api.github.com/users/<作成した App 名>%5Bbot%5D

レスポンスの json の idの値がわかれば、今回作成したApp名はわかるので、email が作れるというわけです。

対象レポジトリの設定ファイルを作成

workflows の yaml で指定した repos-fileのファイルを作成し、実行対象のレポジトリを指定します。

md ファイル形式で列挙して貰えればいいです。

https://github.com/keyno63/scala-steward-mine/blob/2e31af53b972ef50f2393616b855a4e1dddf66ba/repos.md

GitHub Actions を有効化してPR作成

GitHub Actionsからジョブが実行されて、ライブラリの更新があればPRが自動生成されます。

実際に作成されたPR

https://github.com/keyno63/heroku-scala-app/pull/5

作成した App で修正コミットがされていること、PRが生成されていることがわかります。

f:id:keyno63:20211128050140p:plain

ここまでできていれば完成です。

うまくいかなかったこととか、補足とか

補足情報的な項目です。

読まなくても設定は可能なので読み飛ばしてもらっても問題ありません。

うまくいかなかったこと

scala-steward-org/scala-steward-actionの設定に App として動作させるための項目に

github-app-id、github-app-keyを設定するのがあるのですが、

repos/repos-github.md at main · scala-steward-org/repos · GitHub

これを設定した場合に repos-file による、特定のレポジトリのみに対する更新ができませんでした。

まだ中身をちゃんと確認していないので原因は不明

補足

GithubApp を作った理由

GitHub App から自分以外が更新した・PRの生成であることがわかるように作成しています。

「自分の活動履歴が実際のものと異なる」、「自分の作業と区別したい」という理由があったのでこの方法を採用しました。

「自分のコミット・PRでも構わない」という人は作成しなくても問題ないかもしれません。

その場合は workflow 中の token 生成は不要です。

代わりにgithub-tokenには自分のアカウントの token を sercret に設定し、

author-nameauthor-emailは自分の GitHub アカウントに紐づいたものを使用して

使ってください。

GitHub Action 中で token の生成について

GitHub App からの PR にするために使用します。bot からのPRであることを識別してもらうため、workflow の中で token を生成してもらっています。

uses: tibdex/github-app-token@v1の部分があたります。

これをせず、自分の token を secrets に登録、それを利用するとすると、

PRは作成できるのですが、作成者が自分になるという悲しい結果になります。

失敗してしまった例

https://github.com/keyno63/sbt-heroku/pull/4

f:id:keyno63:20211128052432p:plain

コミットは App になっていそうだが、PR作成者は自分のアカウントになる。

author-name, author-email について

author-nameauthor-emailはコミットするときのユーザー情報です。

これも自分の実績と分けたかったので、設定しています。

参考情報

今回の作業にあたり、以下の情報を参考にさせていただきました。

scala-steward-org/scala-steward-action の README
忙しいScala開発者の超時間節約術 by 立野靖博 - YouTube
rpscala - scala-steward についての LT
- https://www.youtube.com/watch?v=udkfR0-cFSg&list=PLcNiTlI1zYsEgQm95C5OgK1NN5FfxBuJZ&t=1595s
xuwei-k さんの scala-steward に関するブログ

最後に

ずっと興味のあった scala-steward が自分のレポジトリに適応できるようになったので感無量です。とてもうれしかった。

*1:GitHub Enterprise や private repository を使っている場合はダメだったかもしれません

*2:このAppはアイコン画像を設定している状態です

*3:項目の説明は後述

はじめに

動機

Visual Studio Code が望まれる理由

Visual Studio Code 設定

Visual Studio Code のインストール

JDK のインストール

SDKMAN を用いたインストール

Java Extension Pack の Getting Start の機能からダウンロードする

各JDKディストリビューションのダウンロードサイトから取得する

Visual Studio Code の設定

拡張パックの追加

Java用の設定追加

設定の完了

最後に

結び

参考

はじめに

該当書籍を読んでみて

おすすめしたい部分

もう少し

はじめに

背景

まえがき

環境

方法

ARM CPU 対応版の Docker ファイルを利用する

その他：アーキテクチャを指定する

docker compose について

終わりに

はじめに

脆弱性バージョン更新の対応

log4j 2 の脆弱性対応について

補足

logback の脆弱性対応

追伸

最後に

はじめに

動機

環境

fat Jar について

fat Jar を作る選択肢

Gradlew にshadow プラグインを使う

すること

build.gradle の編集

fat Jar 生成

動作確認

最後に

はじめに

scala-steward とは

モチベーション

なぜ scala-steward か

GitHub Actions で動かす理由

設定方法

前提条件

設定に必要なこと

設定手順

GitHub App を生成

GitHub App の秘密鍵を生成

scala-steward 実行用レポジトリを生成

secret の設定

GitHub Workflows の作成

補足：app id について

補足：author-email の取得

対象レポジトリの設定ファイルを作成

GitHub Actions を有効化してPR作成

うまくいかなかったこととか、補足とか

うまくいかなかったこと

補足

GithubApp を作った理由

GitHub Action 中で token の生成について

author-name, author-email について

参考情報

最後に

各JDK ディストリビューションのダウンロードサイトから取得する