だれも聞いていないと思って歌え

dance as if no one’s watching, sing as if no one’s listening, and live everyday as if it were your last.

Windows で git commit に署名する

普段 Mac を使っているが久々に Windows で開発することになり、コミットに署名をしたいので調べた。 GPGキーを作成するのに必要なアプリケーションもそれをインストール方法も色々あるようだが、 winget でパッケージ管理できるらしいので homebrew を使うような感覚でこれを使ってみる。

winget とは

winget コマンド ライン ツールを使用すると、Windows 10 および Windows 11 コンピューター上でアプリケーションを検出、インストール、アップグレード、削除、および構成することができます。 このツールは、Windows パッケージ マネージャー サービスに対するクライアント インターフェイスです。
https://learn.microsoft.com/ja-jp/windows/package-manager/winget/

winget と Gpg4win をインストールする

winget search でまずは検索してみる

winget search gnupg
名前                                                          ID            バージョン ソース
-----------------------------------------------------------------------------------------------
GpgFrontend - OpenPGP/GnuPG crypto, sign and key management … 9NH716MQK2B5  Unknown    msstore
GNU Privacy Guard                                             GnuPG.GnuPG   2.4.5      winget
Gpg4win                                                       GnuPG.Gpg4win 4.3.1      winget

複数あるようだが、GitHub Docsで Gpg4win について言及されていたのでそれをインストールする。

winget install Gpg4win
gpg -h

ヘルプが表示されない場合は shell を開きなおして再度 gpg -h を実行してヘルプが表示されることを確認する。

キーの作成

docs.github.com

GitHub Docsの通りに進めていく

gpg --full-generate-key

目的のキー、目的のキーサイズ、キーの有効期限を聞かれるが Enter を押してすべて規定値にする。 ユーザーIDとメールアドレスの入力を求められるので、GitHubアカウントに登録した検証済みメールアドレスを入力する。最後に、パスフレーズを聞かれるので入力して、完了。

GPGキーのリストを表示する。

gpg --list-secret-keys --keyid-format=long

使用したキーによって表示は変わるが、この場合は ed25519/ の後ろをコピーしてGPGキーを表示する。

[keyboxd]
---------
sec   ed25519/XXXXXXXXXXXXXXXX 2024-03-25 [SC]
      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
uid                 [  究極  ] Your Name <your@email.address>
ssb   cv25519/XXXXXXXXXXXXXXXX 2024-03-25 [E]
gpg --armor --export XXXXXXXXXXXXXXXX

-----BEGIN PGP PUBLIC KEY BLOCK----- で始まり、-----END PGP PUBLIC KEY BLOCK----- で終わる GPG キーをコピーします。

GitHubアカウントにGPGキーを追加する。

git に署名設定を追加する

docs.github.com

すべてのコミットに署名するように設定を追加する

git config --global commit.gpgsign true
git config --global user.signingkey <your key>
git config --global commit.gpgsign true
Get-Command gpg | fl
git config --global gpg.program " C:\Users\your name\AppData\Local\Programs\GnuPG\bin\gpg.exe"
git commit

最後に

困った時に参考にさせてもらいました。

zenn.dev

git リポジトリの内容を別の git リポジトリに移す

repoA, repoB のように別々に管理し作業をしていたリポジトリを、統合する必要があったので repoB を repoA にまとめることにした。

変更前

.
├── repoA
└── repoB

変更後

.
└── repoA
    └── repoB

のようにしたい。

今回は、諸事情から git submodule で repoB をサブディレクトリとして登録するのではなく、 repoA で全てのソースコードを管理するように変更します。

手順は、下記記事を参考にしています。

qiita.com

# repoB のディレクトリをリモートとして追加
$ git remote add repoB ../repoB
$ git fetch repoB

# 予め、 repoB という名前のディレクトリを作成
$ mkdir repoB

# repoB の master ブランチを、 repoB ディレクトリにマージ
$ git merge -X subtree=repoB repoB/master --allow-unrelated-histories origin/master

最後のマージ時だが、 --allow-unrelated-histories オプションなしの場合だとエラーが表示される。

$ git merge -X subtree=repoB repoB/master
fatal: refusing to merge unrelated histories

どうやら、履歴の全く異なるブランチをマージする際に表示される警告らしく、オプションをつけることで解決しました。

qiita.com

ついでに、 repoB では GitHub Actions で lint を実行していたので下記のようにディレクトリを指定するように変更。

name: lint
on:
  push:
    paths:
      - 'repoB/*'
      - '.github/workflows/lint.yml'

defaults:
  run:
    working-directory: ./repoB

jobs:
  lint:
    runs-on: ubuntu-latest
      ...

lint の実行を、 repoB と、このファイル自身である lint.yml に限定し、コマンドの実行時に対象としたいディレクトリを working-directory で初期設定する。

cd コマンドは書く必要がなく、 repoB ディレクトリ下の package.json と紐づいた内容が無事に実行されるようになりました。

docs.github.com

github.community

yarn のインストールを npm から brew へ変更した

Node.js yarn

yarn のインストールをずっと npm install -g yarn というコマンドで実行してきたが、 node のバージョンを変えるたびに yarn も合わせてインストールしなくてはいけなく若干面倒さを感じていた。

homebrew から yarn もインストールできると知ったので早速切り替えることにしたのでついでにメモとして記事に残す。

brew install yarn --ignore-dependencies

インストール | Yarn#macOS を参考に、上記コマンドを実行。 Node.js のバージョンは nodenv で管理しているため、 Node.js を除外するようにオプションを指定してインストールする。

% which yarn
/Users/<username>/.nodenv/shims/yarn
% yarn -v
1.17.3

yarn の向き先が変わっていないので、 npm コマンドで yarn をアンインストールする。 それでも which yarn を実行しても切り替わらなかったため、 rm コマンドで which コマンドで向いている先のディレクトリを削除する。

% rm -rf /Users/<username>/.nodenv/shims/yarn/
% which yarn
/usr/local/bin/yarn
% yarn -v
1.22.4

向き先が代わり、無事 yarn コマンドも実行できました！

Gradle + Spring Boot で Hello World

Java

Java エンジニア向けの内容ではないです。

普段フロントエンドをやっているエンジニアが、案件の合間に先輩に教わりながら Java で Hello World した時のメモです。

本当は今携わっているプロダクトのバックエンドのシステムそのものをローカル環境で動かしたかったのですが、 Mac 向けの環境構築手順がなく、不慣れな言語の不慣れなフレームワークで手こずったため挫折しました。。。

1. JDK のインストール

Java の実行環境がないため、まずは現在最新の JDK 12 をダウンロード。

jdk.java.net

展開します。

% tar xvzf openjdk-11+28_osx-x64_bin.tar.gz
% sudo mv jdk-12.0.1.jdk /Library/Java/JavaVirtualMachines/
% /usr/libexec/java_home -v
Matching Java Virtual Machines (1):
    12.0.1, x86_64: "OpenJDK 12.0.1"    /Library/Java/JavaVirtualMachines/jdk-12.0.1.jdk/Contents/Home

次に、パスを通します。

% export JAVA_HOME='/usr/libexec/java_home'
% java -version
openjdk version "12.0.1" 2019-04-16
OpenJDK Runtime Environment (build 12.0.1+12)
OpenJDK 64-Bit Server VM (build 12.0.1+12, mixed mode, sharing)

インストールした JDK の情報が表示されたので、これでインストールは完了です。

手順等はこちらを参考にしました。 qiita.com

ちなみに、JDK とは Java Development Kit のことで、 Java のプログラミングに必要なツール群を指します。

詳しく知りたい場合はこちらの Oracle の公式動画が分かりやすかったです。

youtu.be

続きを読む

CircleCI 2.0 で ESLint を実行する

CircleCI

仕事で CircleCI に触れてはいたが、プライベートでも導入することにしてみました。
GitHub アカウントと紐付けてアカウントを作成し、リポジトリを指定してセットアップを行うと、 OS 、 Platform 、 Language が自動的に選択されてconfig.ymlのサンプルが生成されました。便利。

f:id:fanjia:20180101171447p:plain f:id:fanjia:20180101171500p:plain f:id:fanjia:20180101171514p:plain

CircleCI CLI をインストールし、ローカル環境で実行する

CircleCI 2.0 では CLI が用意され、ローカル環境での実行、config.ymlファイルのシンタックスチェックなどが行えます。

circleci.com

1.Docker のインストール docs.docker.com

2.CLI のインストール

% curl -o /usr/local/bin/circleci https://circle-downloads.s3.amazonaws.com/releases/build_agent_wrapper/circleci && chmod +x /usr/local/bin/circleci

3.config.yml のシンタックスチェック

% circleci config validate -c .circleci/config.yml
Receiving latest version of circleci...
  config file is valid

4.ローカル環境で実行する

% circleci build

ローカル環境での実行ではキャッシュをサポートしていないため、 restore_cache や save_cache では以下のようなエラーが表示されます。

====>> Restoring Cache
Error: Skipping cache - error checking storage: not supported

Step failed

5.Lint チェックを追加する

eslint の実行時に結果を Junit で出力し、その出力したファイルを store_test_results と store_artifacts に設定して CircleCI 上で結果表示を行うようにする。

- run:
    name: lint check
    command: |
      mkdir -p ./reports
      npx eslint ./app/ --format junit --output-file ./reports/eslint.xml
- store_test_results:
    path: ./reports
- store_artifacts:
    path: ./reports

その他

Git Hook に config.yml のシンタックスチェックを仕込む

CircleCI CLI の手順にあったので、追加。 circleci.com

.git/hooks/pre-commitに設定を追加することでコミット時にチェックが行われ、エラーになる場合に下記のようなエラーが表示されます。
また、 Docker を起動していない場合も同様にチェックができないため失敗します。

CircleCI Configuration Failed Validation.

CircleCI 関連で以前書いた記事です。

38fanjia.hatenablog.com

38fanjia.hatenablog.com

STG 環境として heroku で静的ページを作成する

Heroku Git

Bitbucket 上にリポジトリを用意して静的ページを作成し、作成したものを他の人に確認してために環境を用意することにしました。

Netlify という静的サイトのホスティングサービスを使おうとしたけれど、無料の範囲内では Basic 認証ができないため断念。。。
まだ作成したものが採用されるとも限らないので、できる限り無料の範囲内でやりたいし、関係者以外に見られたくないので Basic 認証はどうしても行いたい。

調べた結果、 Heroku 上で静的ページを公開するための設定を用意したリポジトリがあったのでそちらを利用してみることにしました。

qiita.com

github.com

リポジトリの作成

作成した静的ページのリポジトリと、 Heroku 用のリポジトリを別にして新たに作成する。
手順は、こちらのページを参考にしました。

qiita.com

静的サイトを submodule として追加する

静的サイトを submodule として追加するため、用意されている public ディレクトリを削除して submodule を追加します。
また、リポジトリの指定方法に決まりがあるようだったのでそちらに合わせて設定する。

devcenter.heroku.com

$ rm -rf public
$ git add public
$ git commit -m 'remove default public'
$ git submodule add https://<user name>:<password>@bitbucket.org/<user name>/<repository name>.git public
$ git commit -m 'add submodules'

Procfile を編集する

静的サイトのリポジトリで、いくつかのパッケージをインストールする必要があるため Procfile を編集します。

web: cd public && npm install --production && cd .. && node server

最後に、 Heroku へ push する

Git ではなく Bitbucket を使用しているため、手動で設定します。

$ git remote add heroku https://git.heroku.com/<repository name>.git
$ git push heroku master
$ heroku config:set USER=<user>
$ heroku config:set PASS=<password>

完成！ 🎉