自分専用のELPA(Emacs Lisp Package Archive)をGitHubでホストしよう

序文

前回の記事では、パッケージの作り方を扱いました。パッケージを作ったら、今度は自分のEmacsに導入したいと考えるでしょう。これを行う方法もいろいろあります。 Emacsのパッケージマネージャを以下に列挙してみます。 GNU GuixやNix、aptなどの汎用パッケージマネージャは除いています。

中央集権型
- package.el(標準)
分散型
- el-get(ただしpackage.elを透過的に利用可能らしい)
- Cask
- elpaca
- straight.el
- quelpa

この分類は、パッケージのビルドがどこで行われるかに着目しています。適当なレシピ、つまりパッケージ定義が与えられた下で、中央集権型はサーバーにおいてビルドされたパッケージをダウンロードするタイプ、分散型はローカルでビルドするタイプのパッケージマネージャです。

この二つのタイプに明確な優劣があるわけではなく、一長一短です。中央集権型の場合には、ローカルにパッケージをビルドする環境を用意する必要がないメリットがあります。分散型だと環境によってローカルビルドが失敗したり一部のファイル(ドキュメント)などが欠けたりする可能性があります (ただし現実的に問題になることはほとんどない)が、中央集権型では(通常ユーザーではない人の管理する)ビルドサーバーの環境さえ整っていれば、ユーザー側では一切の準備なく完全なパッケージを利用可能です。

一方分散型の場合には、一度レシピ一覧さえダウンロードしてしまえば、レシピを配信するサーバーが落ちてもビルド自体はローカルなので問題にならないというメリットがあります。もちろんソースコードを頒布するサーバーが落ちている場合はビルドできませんが、それはパッケージ単位の話で、全てのパッケージを少数のサーバーに依存する中央集権型にはないメリットです。ただし、 GitHub や GitLab をはじめとした有名なホスティングサービスでホストしたパッケージが大半なので、実質的には少数のサーバーに依存してしまっているのが現状です。

中央集権型がpackage.elしかなく、分散型がほとんどを占める理由はおそらく単純で、中央集権型ではサーバー管理が必要になってくるからだと思います。新しいパッケージマネージャを作ろうと思ったとき、package.elと異なる配信のしかたをするのであれば、わざわざパッケージをビルドして配信するサーバーを用意せねばなりません。サーバーを用意しても利用してもらえなければ意味がないし、利用されすぎても管理費がかかる上、同じ形式のサーバーが他にも立たないと他のパッケージマネージャに対してあまりメリットがなくなってしまいます。一方package.elと同様の配信形式をそのまま利用するのであれば、単にpackage.elをバックエンドとすればよいでしょう。すると必然的にpackage.elのラッパとなります。

中央集権型のpackage.elにはもう一つ大きなデメリットがあります。それは、気軽にパッケージを追加できないことです。分散型の場合、ローカルにビルド環境が必要ですが、それさえ用意してしまえば、レシピを経由して自作パッケージと他の人のパッケージを統一的に扱うことができます。しかし中央集権型の場合、ビルド及び配信を行うサーバーを別途用意する必要があります。 package.elはローカルのディレクトリをビルドサーバーに見立てて利用することが可能ではありますが、その場合、結局ローカルのビルド環境を用意しなければならなくなり、あまり中央集権型の恩恵は受けられません。さらに、ローカルでのビルドを前提としている分散型とは違い、ビルド環境を用意するのはかなり面倒になります。

そこで、なんらかのホスティングサービスを利用してパッケージをインターネット上に公開することを考えます。パッケージの配布自体は静的サイトでよく、ビルドを定期的に走らせることで最新のパッケージに更新すればよいです。

ここでは、GitHub ActionsとGitHub Pagesを用いてパッケージをビルドし、パッケージを配布するところまでを行います。実際にはこのサービスを絶対に利用しなければならないわけではないです。簡単にGitLabなどの他のサービスへと移植できるよう、なにを行っているかを順に説明するつもりです。ただし、各パッケージのビルドの具体的なプロセスについてはpackage-buildによって隠蔽されており、利用にあたって深く知る必要はないため、あまり詳細に解説はしません。

テンプレートの利用

今回は、template-github-elpaを利用して解説していきます。このテンプレートはgithub-elpaを直接の依存としており、これを利用するための諸々の準備を整えるためのテンプレートです。 github-elpaはCLIから直接呼びだせるようになっており、READMEではCaskを利用するように書いています。しかし、そこに書かれている cask exec コマンドは既にCaskから削除されており、そのままでは利用できません。そこで、このテンプレートでは keg を用いた実行に書きなおしています。ここで keg を選んでいる理由は特になく、単に私が慣れているからです。

詳しくは後述しますが、このテンプレートを利用する場合、 recipes/ 以下にレシピを書いて keg run build すれば、 docs/elpa/ 以下にパッケージアーカイブが作成されます。

使用方法

ここでは、github-elpaを使うことに焦点を当てた説明を行います。具体的になにをしているのか、詳細な説明は次章をご覧ください。

また、手元で実際のビルド結果を確認したい場合は、あらかじめkeg.elをインストールしておいてください。 Emacsが既にインストールされていれば、クローンしてパスを通すだけで動きます。なお、このツールはEmacs Lispパッケージ及びプロジェクト管理のためのツールで、 npm や yarn のようなものです。デファクトスタンダードは特にないため、私の好みでこれを使っているだけです。

さて、順に使用方法を述べていきます。

テンプレートの使用

まず、template-github-elpaをテンプレートとして、GitHubでレポジトリを作成してください。ここで作ったレポジトリ名を仮に yourreponame とします。すると、ユーザー名を yourname としたとき、今作成したレポジトリのURLは https://github.com/yourname/yourreponame となるはずです。ちなみに、ここでそれっぽい名前を付けると愛着が湧きます。

レシピの作成

recipes/ 以下にレシピを書きます。ここで言うレシピとは、package-buildが認識できるフォーマットによって書かれたパッケージの定義のことです。パッケージのソースコードがどこにあるか、そのうちどのファイルを配布するのか、などを指定します。なお、レシピはパッケージ管理システムによってフォーマットが異なる場合があることに注意してください。レシピ自体はEmacs標準の概念ではなく、単にサードパーティのパッケージ管理システムやパッケージビルダーがパッケージの指定を簡単にするために導入したものです。

以下にMELPAのREADMEにあるレシピのフォーマット (package-buildはMELPAプロジェクトの一部で、レシピのフォーマットはここを見るようにpackage-buildのREADMEに書いてある)を転載します。なお、S式としてパースされるため、改行は空白と等価です。また、 [] 内は省略可能、もしくは選択肢のなかから選ぶ方式を取る値です。

(<package-name>
 :fetcher [git|github|gitlab|codeberg|sourcehut|hg]
 [:url "<repo url>"]
 [:repo "user-name/repo-name"]
 [:commit "commit"]
 [:branch "branch"]
 [:version-regexp "<regexp>"]
 [:files ("<file1>" ...)]
 [:old-names (<old-name> ...)])

通常、ファイル名は <package-name> と同一にします。主要なキーワードだけ軽く説明します。

<package-name>

パッケージの名称。 package-list-packages などではこの名前で見える。メインのファイルは <package-name>.el であることが推奨される。

:fetcher

対象のパッケージのソースコードがどこでどうホストされているかを示す。 github 、 gitlab 、 codeberg 、 sourcehut の4つのホスティングサービスには直接対応している。それ以外でホストしている場合は、利用しているバージョン管理システムに応じて git か hg を指定する。

:repo

レポジトリを表す文字列で、 ユーザー名/レポジトリ名 のようなものを与える。なお、これは :fetcher でホスティングサービスを直接指定したときにのみ有効。

:url

レポジトリのURL。 :fetcher でバージョン管理システムを指定したときにのみ有効。

:files

対象パッケージに含むべきファイル名に一致する正規表現のリスト。なお、このリストの末尾の要素は (:exclude "正規表現"...) でもよく、ここにある正規表現に一致するファイルは、たとえ含むべきファイルの正規表現に一致したとしても除外される。なにも指定しなければ以下の値になる(MELPAのREADMEより転載、最新の情報は転載元を確認してください)。

'("*.el" "lisp/*.el"
  "dir" "*.info" "*.texi" "*.texinfo"
  "doc/dir" "doc/*.info" "doc/*.texi" "doc/*.texinfo"
  "docs/dir" "docs/*.info" "docs/*.texi" "docs/*.texinfo"
  (:exclude
   ".dir-locals.el" "lisp/.dir-locals.el"
   "test.el" "tests.el" "*-test.el" "*-tests.el"
   "lisp/test.el" "lisp/tests.el" "lisp/*-test.el" "lisp/*-tests.el"))

もしデフォルトのファイル群に付け足す形で指定したい場合は、リストの先頭要素として :defaults を書くとよい。そうすると、上記のデフォルトに加えて、リストの先頭でない要素の正規表現にマッチしたファイルが認識される。

さて、レシピの簡単な説明を終えたところで、レシピを書いてみましょう。コピペで動くように、とりあえず存在するパッケージをそのまま利用します。例として今回用意した特になにもしないパッケージであるdummy-exampleを用います (他人の書いたパッケージが今後存在し続けることを担保するのが面倒なのでダミーのパッケージを用意しました)。自分で定義したパッケージがあるのなら、是非そちらに書きかえてみてください。

;; ファイル名: recipes/dummy-example
(dummy-example :fetcher github :repo "ROCKTAKEY/dummy-example-el")

書き方は先ほどの通りで、ファイル名とパッケージ名を一致させ、 fetcher はコードがGitHubにあることから github に指定、ユーザー名 ROCKTAKEY でレポジトリ名 grugru なので :repo に "ROCKTAKEY/grugru" と指定します。自分のパッケージを作成したい場合は適宜置き換えてください。なお、レシピの編集のためのメジャーモードとして package-recipe-mode というモードがpackage-buildパッケージで提供されているので、是非お使いください。

ビルド

レシピを書いたので、手元でビルドしてみます。なお、この操作自体は必須ではなく、レシピさえコミットしてしまえばGitHub Actionsでビルドしてくれます。ただし、ビルドすることでなにが起こるか、正常にビルドできるか確かめるために手元で実行しておくことが望ましいです。

この章の最初で述べたようにkeg.elをインストールしたら、クローンしたあなたのレポジトリで以下を実行してください。

keg install
keg run build

一行目でgithub-elpa及びその依存先をインストールし、二行目でレシピからパッケージをビルドします。ほぼ Keg ファイルに書いてある通りですが、二行目は emacs --batch -Q --eval (require 'github-elpa) -f github-elpa-build を(github-elpa及びその依存先にload-pathを通した上で) 実行しているだけです。 github-elpa-build という関数がレシピからアーカイブを作成してくれます。成功すれば、二行目に対する出力として以下のようなものが得られるはずです。

Install dependencies
 DevDependency: ((github-elpa 0.0.1))

All dependencies already satisfied
Exec command: keg emacs --batch -Q --eval \(require\ \'github-elpa\) -f github-elpa-build
Exec command: emacs --batch -Q --eval \(require\ \'github-elpa\) -f github-elpa-build


:: github-elpa: packaging recipe dummy-example
Package: dummy-example
Fetcher: github
Source:  https://github.com/ROCKTAKEY/dummy-example-el.git

Cloning https://github.com/ROCKTAKEY/dummy-example-el.git to /home/rocktakey/sandbox/template-github-elpa/.github-elpa-working/dummy-example/
Checking out 4776eee32b38dbfcdd45b2d87e2c5ce989e5ce05
Built dummy-example in 0.908s, finished at 2023-02-20T17:02:09+0000

各パッケージにどんなファイルが含まれているかなど、ビルドの詳細が出力されています。複数のレシピがあれば複数のログが出力されるはずです。なお、ビルド生成物は ./docs/elpa/ 以下に出力されています。

コミット及びデプロイ

最後にこれをコミットしましょう。すると、GitHub Actionsによって自動的にビルドされ、パッケージアーカイブが https://yourname.github.io/yourreponame/ にデプロイされます。なお、デフォルトでは cron を用いて毎日1回ビルドが走るようになっています。適宜変更してください。

./.github/workflows/pages.yml を見るとわかりますが、先ほど手元で行ったビルドプロセスと全く同じことを実行した上で、 GitHub Pagesに ./docs/elpa/ 以下をデプロイしているだけです。また、PRなどに対してビルドテストが走るようにしています(./.github/workflows/test.yml を参照)。テストでも同様にビルドを走らせているだけです。ここまでわかっていれば、GitLab Pagesなどの他のサービスでも同様のことができるはずです。

自分のEmacsで使ってみる

init.elを変更して、package.elにアーカイブの場所を教えてあげましょう。以下をinit.elに追加してください。 好きな名前 のところは好きな名前に置き換えてください。レポジトリの名前と揃っているとわかりやすいかもしれませんが、必須ではありません。ここの名前はパッケージをリスト形式で並べるときに出てくるので、自分の識別しやすい名前にしてください。

(add-to-list 'package-archives '("好きな名前" . "https://yourname.github.io/yourreponame/"))

ここで package-list-packages を実行すると、パッケージのリストが画面に表れます。しばらくするとリフレッシュ(パッケージアーカイブの最新情報をURLから取ってくる操作)が終了し、新しいパッケージがリストに追加されます。以後、このリストで i を押してパッケージをマークしてから x を押すか、 package-install コマンドを使うことでインストールできます。また、リストせずにリフレッシュだけしたい場合は package-refresh-contents コマンドを実行すればよいです。

デプロイ頻度について

ここではデプロイの頻度の変更方法について軽く触れておきます。

現在の設定では、毎日1回世界標準時0時にビルドが自動で走ります。これは .github/workflows/pages.yml の冒頭付近において、 on.schedule で cron を指定していることによります。毎日1回世界標準時0時にジョブを実行するために 0 0 * * * を指定しています。 cron の書式は解説しませんが、この値は自分の用途に合わせて変更してください。

技術的な仕組みの説明

この章はパッケージアーカイブがどのような仕組みで構成されているかを説明します。先ほどのテンプレートを使用するだけであればこの章を読む必要はありません。

パッケージアーカイブの仕組み

そもそもパッケージアーカイブとは、どのようなディレクトリ構成になっていればよいのでしょうか。それさえ把握してしまえば、 package-build や github-elpa を利用しなくとも自分だけのパッケージビルダを用意することができます。

パッケージアーカイブのディレクトリ構造は、ルートディレクトリに対して以下のようになっています。

.
├── archive-contents
├── package1-20230220.1700.el
├── package1-readme.txt
├── package2-20230121.1825.tar
└── package2-readme.txt

大きくわけると4種類に分けられます。

アーカイブ全体についてのファイル
- archive-contents ファイル
各パッケージについてのファイル
- *.el / *.tar ファイル
- *-readme.txt ファイル
- *.entry ファイル

これらのそれぞれについて解説していきます。

`archive-contents` ファイル

このファイルは、package.elのリフレッシュの際に用いられます。このファイルはアーカイブがどのようなパッケージを持っているかを保持しています。このファイルはリフレッシュの際に ~/.emacs.d/elpa/archives/アーカイブ名/ 以下に保存され、リフレッシュ後や package-initialize 時に package-read-archive-contents 関数によって package-archive-contents に読み込まれます。読み込む際には package-desc という構造体に格納するため、元のファイルの内容と少し異なりますが、もっている情報は同一です。

さて、ファイルの持つ値としては car がアーカイブのバージョン(通常は 1)、 cdr は連想リスト(associationa list; alist)になっています。この連想リストは、キーがパッケージを表すシンボル、値が配列になっています。この配列がパッケージの詳細を保持しています。保持している情報は配列の頭から順番に以下になっています。なお、これらは package--ac-desc という別の構造体を作成するときのコンストラクタ package-make-ac-desc に渡ります。

バージョン: パッケージのバージョンをリストで表したもの。バージョンが 24.1 ならば (24 1) 。
依存のリスト: 依存対象のリスト。各要素はサイズ2のリストで、1つ目の要素が依存対象のパッケージを表すシンボル、二つ目の要素がバージョン(先程のバージョンと同様のフォーマット)。
要約: パッケージの短い説明文。通常はパッケージのメインのファイルの行頭のコメントが文字列として格納される。
種別: パッケージが1ファイルかそうでないか、どのような形式であるかを格納する。 single シンボルであれば1ファイル、 tar であれば複数ファイルをtar形式でまとめたもの。ディレクトリを表す dir を想定したようなコードがpackage.elの一部で見られるが、まだ対応していない(dir を弾くコードがある)。
その他の情報: その他の情報を持った連想リスト。 describe-package-1 などで利用される。コミットハッシュ :commit 、筆者 :author (名前とメールアドレスのコンスセル)、メンテナ :maintainer (筆者と同様)、 URL :url 、パッケージの属するキーワード =:keywords=などがキーとして典型的である。ここで挙げた以外のキーは今のところ特に使われていないように見える(特に一覧などがあるわけではないので確実ではない)。

`.el` / `.tar` ファイル

先ほど述べた「種別」が single か tar かによって、どちらのファイルを見るかどうかが変わります(package-desc-suffix を用いて拡張子を出しわけている)。

*.el ファイルの場合は パッケージ名-バージョン.el が存在しなければなりません(インストール時には パッケージ名.el としてインストールされる)。 *.tar ファイルの場合も パッケージ名-バージョン.tar が存在する必要があり、展開すると パッケージ名-バージョン/ ディレクトリに展開される必要があります。そのディレクトリの中身のファイルはほとんど自由ですが、ただ一つ パッケージ名-pkg.el の存在が要求されます。ここにはパッケージ定義、すなわち define-package 式が記述されている必要があります。この関数が呼び出されることはなく、単にパッケージ定義を置くためだけにあるものです。持っている情報は先ほどの archive-contents と全く同じで、上位4つの引数がパッケージ名(ここでは文字列)、バージョン(文字列)、要約、依存を表すリスト(クオートする必要あり)となっています。残りの引数はキーワード引数で、 archive-contents 「その他の情報」と全く同様の内容を渡すことができます。

`*-readme.txt` ファイル

パッケージの詳細な説明文が格納されている。名前は パッケージ名-readme.txt である必要がありますこの値は describe-package などでパッケージの詳細を見ようとしたときに表示されます。

通常はメインの .el ファイルの Commentary セクションの内容が格納されますが、自分でパッケージビルダーを作る場合は README.md や README.org から生成してもよいかもしれません。

`*.entry` ファイル

先ほどのテンプレートを利用した場合、 パッケージ名-バージョン.entry ファイルができていると思います。これは package-build パッケージのためのファイルであり、package.elがアーカイブとして認識するには必要ないファイルなので、リストには入れていません。中身は archive-contents のうち該当パッケージの要素が書いてあるだけです。

テンプレートはなにをしてるのか

さて、テンプレートに含まれているファイル群はいったいなにをしているのでしょうか。テンプレートに含まれているファイルは以下のようなものがあります。

.github-elpa-working/.gitkeep
.github/workflows/test.yml
.github/workflows/pages.yml
recipes/.gitkeep
.gitignore
Keg
LICENSE
README.org

見ての通り、動作するのに意味のあるファイルはほとんどありません。

`.github-elpa-working/.gitkeep` 、 `recipes/.gitkeep`

これらのファイルの中身は空で、中身自体に特に意味はありません。 gitでは空のディレクトリをコミットで保持することはできないため、ディレクトリを保持したい場合は慣習として .gitkeep を置くことが多いです。

.github-elpa-working はビルドの際に利用されるディレクトリで、 package-build の2022/12/17のコミットのどれか(未調査)により実行時に存在する必要があるディレクトリになりました。

recipes/.gitkeep はたしか実行時に必要なディレクトリではなかったかと思いますが、ないとどこにレシピを追加するのかわかりにくいので置いてあります(recipes じゃなくて recipe にしちゃうとかあるあるなので)。

`.gitignore`

おそらく説明は不要でしょうが、Git管理しない(変更を検知しない)ファイル群です。ビルド生成物を含む docs/ 以下、 keg コマンドによってダウンロードされた依存を含む .keg 以下、ビルドの途中の中間生成物を置く .github-elpa-working/ 以下を指定しています。

docs/*
.keg/*
.github-elpa-working/*

`LICENSE`

ライセンスファイルです。これはテンプレート自体のライセンスも兼ねています。大した内容じゃないので著作権が生じているか怪しいですが、GNU Affero General Public License (AGPLv3)としています。 Emacs自体がGPLでライセンスされていることもあり、Emacs周りのライセンスはGPLやAGPLがほとんどです。

`Keg`

このファイルは、keg.elというツールの設定ファイルです。 keg.elはパッケージマネージャですが、コマンドランナー的な役割も兼ねています。内容は以下のようになっています。

(source gnu nongnu melpa)

(dev-dependency github-elpa)

(script
 (build
  (keg-shell
   '("keg" "emacs" "--batch" "-Q" "--eval" "(require 'github-elpa)"
     "-f" "github-elpa-build"))))

source で依存するパッケージアーカイブを指定、 dev-dependency で依存を指定しています。

script では (build ...) を与えることで build という名前のスクリプトを定義しています。このスクリプトは keg run build で走らせることができます。 ... のところには任意のEmacs Lispを書くことができます。 keg-shell はシェルコマンドを実行する関数です。今回は keg emacs --batch -Q --eval (require 'github-elpa) -f github-elpa-build を実行しています。 keg emacs コマンドは emacs を直接呼び出すのとほとんど同じですが、環境変数を通じて .keg にある依存ファイルに load-path (Emacs Lispにおける PATH のようなもの) を通した状態で emacs を実行してくれます。

`.github/workflows/test.yml` 、 `.github/workflows/pages.yml`

先に述べておきますが、私はGitHub Actionsの玄人ではないので、この節の説明は信憑性が他よりやや低いです。基本的にdeploy-pagesのページに基づいて作成しているので動かないことはないと思いますが、説明として間違ったことを言っている可能性は十分にありますので、留意しておいてください。

これらはGitHub Actionsの設定ファイルです。 pages.yml はデフォルトブランチへのプッシュ時、及び毎日一回、レシピからパッケージアーカイブをビルドし、デプロイを行います。 test.yml はあらゆるプッシュ及びプルリクエストに反応し、ビルドがきちんとできるかだけを確認します。

両者の内容はほとんど同じで、 test.yml は pages.yml にほぼ包含されるので省略します。具体的には、 pages.yml に含まれるビルドの部分がプッシュとプルリクエストの時に自動で走るようにしています。

pages.yml の内容を以下に示します。

name: pages

on:
  push:
    branches: ["master"]
  schedule:
    - cron:  '0 0 * * *'
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3
      - uses: purcell/setup-emacs@master
        with:
          version: "28.2"
      - uses: conao3/setup-keg@master

      - run: keg install
      - run: keg run build

      - name: Upload artifact
        uses: actions/upload-pages-artifact@v1
        with:
          path: 'docs/elpa'

  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v1

この記事はGitHub Actionsの解説記事ではないので、全部は解説しません。この記事において特有のところを取り上げて説明します。

on.push.branches でデフォルトブランチを指定することで、デフォルトブランチにプッシュした場合にジョブが走るようになります。また、少し前にも触れましたが、 on.schedule で cron を指定することで、定期的にジョブを走らせることができます。 cron 引数の意味はここでは解説しません(cronで検索すれば沢山出てくると思います)が、 0 0 * * * で毎日1回世界標準時0時にジョブを実行します。ここは自分の用途に合わせて変更してください。

permissions はGitHub Pagesに直接デプロイするのに必要な記述です。詳しくはdeploy-pagesのページをご覧ください。

これ以降はジョブがわかれているので、分けて説明します。なお、ここで使っている「GitHub ActionsからGitHub Pagesに直接デプロイする」という機能はパブリックベータなので、今後使用方法が変わる可能性があります。もしテンプレートが使えなくなっていたら、Issueやメールなどで遠慮なく私に連絡してください。

build ジョブ

このジョブでは、パッケージアーカイブのビルドを行います。

purcell/setup-emacs@master でEmacsをインストールします。 version 引数でインストールしたいEmacsのバージョンを指定します。

conao3/setup-keg@master でkeg.elをインストールします。

その後、先ほど述べたように keg install で依存をインストールし、 keg run build でパッケージアーカイブをビルドします。

最後に actions/upload-pages-artifact@v1 でビルド生成物をアップロードします。 actions/upload-pages-artifactは path 引数で与えたパス以下にあるファイル群を、GitHub Pagesのために自動でアップロードしてくれます。ただしここではアップロードするだけで、デプロイは別のジョブで行う必要があることに注意してください。

deploy ジョブ

build ジョブの後にこのジョブが実行されます(needs: build となっているため)。ここではGitHub Pagesにデプロイを行います。このジョブが終わると https://yourname.github.io/yourreponame/ からパッケージアーカイブにアクセスできるようになります。

ここではdeploy-pagesを用います。

まず environment で環境を github-pages に指定し、同時にデプロイ先のURLを指定します。この環境は先ほどのactions/upload-pages-artifactによって作成されたもので、これによってdeploy-pagesが実行される環境が整います(このへんの機能を使うことがあまりないのでよくわかっていない)。

あとは actions/deploy-pages@v1 を実行するだけです。 IDとしては deployment を指定します (おそらく deploy.environment.url に指定している step.deployment... の部分と一致していることが重要だと思うが、詳細は不明。実験してみればすぐわかると思います)。

最後に

この記事では、template-github-elpaというテンプレートを通じて自分だけのパッケージアーカイブを作成する方法を説明しました。ちなみに私は自分のパッケージアーカイブとしてroquelpaを作っています。自分だけのパッケージアーカイブを持っておくと、自分のパッケージを登録できるだけでなく、使いたいけどどこのアーカイブにも登録されていない他人のパッケージを登録したり、バグが修正されていないパッケージをフォークしてバグを直した上で一時的に登録したり、色々な使いかたができます。是非みなさんも自分だけのパッケージアーカイブを作成してみましょう。

序文#

テンプレートの利用#

使用方法#

テンプレートの使用#

レシピの作成#

ビルド#

コミット及びデプロイ#

自分のEmacsで使ってみる#

デプロイ頻度について#

技術的な仕組みの説明#

パッケージアーカイブの仕組み#

archive-contents ファイル#

*.el / *.tar ファイル#

*-readme.txt ファイル#

*.entry ファイル#

テンプレートはなにをしてるのか#

.github-elpa-working/.gitkeep 、 recipes/.gitkeep#

.gitignore#

LICENSE#

Keg#

.github/workflows/test.yml 、 .github/workflows/pages.yml#

最後に#

序文