ブログ on えやみぐさ

えやみぐさの記事運用 2022-06-24

Fri, 24 Jun 2022 09:30:00 +0900

技術ノートチャンネルには「具体的な解決策が見つかったものを報告・共有する記事」を載せたかったかもしれない。

わかりませんでした。いかがでしたか？　を避けたい。

でも、具体的な解決策がわからないんだけど、これどうしたらいいのか悩んでる、ということを共有する記事もほしい。 Twitterに投げるには分量が多いとか。

未解決タグを付ける方法はありそう？でも20%くらい解決したんだけど…みたいな場合に中途半端な未解決タグが付きそう。

前の記事を参照して、解決策1個みつけたわ、みたいな記事があってもいいと思うんだけど、それが100%の解決策でなかったりする場合にベストアンサーではないよねみたいなことがある。質問IDでも振って紐づけるか？？？

この記事にリンクしている記事一覧とかあればそれでいいのか？（実装が面倒かも？）まあタイトル詐欺しなければどういう運用しても別にいいのでは…

記事が増えすぎて質が落ちる・埋もれるかもしれんという問題はあるかも？先にJoplinとかScrapboxとかである程度整理してからの方が雑記事になりにくそう。

そういうのを作業ログチャンネルに入れたかったんだけど、なんだかんだそのレベルの文章をアップロードするのは面倒くさい。

記事としてのまとまりが悪くなりがちな気がする（話題があちこち飛んだり、矛盾した考えがあったりする）。

JoplinとかScrapboxに書くのがちょうどいい？　うーん。

https://blog.aoirint.com/entry/2022/pip_compile_metadata_generation_failed/

上を書くにあたって、Joplinに下書きして、記事としてまとめたものを公開して、下書きをScrapboxに公開する、とバージョン違いのコピーが3個できた。

Joplin: コンセプトがはっきりしないMarkdownの下書き
ブログ: 一応方針を固めたもの、Markdown
Scrapbox: Joplinの下書きをScrapbox書式に修正したもの

これがこういうバージョン違いなんですよ、ということを説明するDBがほしくなる。

バージョンの同期とか面倒だし、あんまりいろんなところに分散させたくないな、とは思うんだけど、いきなりScrapboxに書くのは軽重問わずセンシティブな情報が事故で公開されるということが起きそうで怖い。

でも正直、バージョン管理とか面倒なことを考えているのは無駄な気もする。

記事を書くモチベーションを上げたいんだけど、それとは関係ないのではと思った。

今回については、はじめは自分用のメモのつもりで書いていたけど、Joplinだとどんどん新しいノートが増えて埋もれるし、あんまり検索にヒットしなくて公益性があるなと思ったから記事化した。

埋もれることについては、だいたいキーワードを総当たりの文字列検索でなんとかなるんだけど、ちょっとしたメモ書きは整理するのが難しいし、Joplin上には1700ノートくらい、Evernoteにはツイートとかも保存しているから42000ノートくらいあって、この中に埋もれさせるのは微妙な感じがする…

それよりも、SSGに10分かかるのが微妙。

あと、noindexした記事がGitHubの公開リポジトリを通じてGitHub Searchにひっかかったり、Googleにインデックスされる可能性があったり、いまの実装だとnoindexなのにサイトマップに送信されてしまったりが微妙。

雑記チャンネルは、検索性・一覧性を悪くするためにわざとタイトルを付けなかったり、複数の内容を1記事に収めたりしていたんだけど、古いやつをちょっと分割してみた。

粗探しをする人とかエゴサーチャーとか正義の晒し屋とか伝書鳩とかに見つかりにくくしたいんだけど、ある程度こなれてきたらいいのかなとちょっとだけ思った（麻痺）。

はてなブログから古い記事を移した

Tue, 22 Feb 2022 20:40:00 +0900

新しい記事 blog.aoirint.com へ投稿しつつ、古い記事は aoirint.hatenablog.com に残っていましたが、古い記事を blog.aoirint.com に移しました。

古い記事にはリダイレクトと移動先へのリンクを設置しています。

https://github.com/x-motemen/blogsync

blogsyncで記事を取得したあと、以下のようなスクリプトでfrontmatterを変換しました。

以前の移行時の作業ミスでMarkdown記事がHTMLになってしまっていたので、手動でMarkdownに書き戻しました。

import glob
import yaml
from datetime import datetime
from pathlib import Path
import frontmatter as FM

for path in glob.glob('**/*.md', recursive=True):
  if path.startswith('output'):
    continue

  print(path)
  with open(path, 'r') as fp:
    frontmatter = FM.load(fp)
    # docs = yaml.safe_load_all(fp)
    # frontmatter = next(docs)
    # body = next(docs)

  body = frontmatter.content
  print(frontmatter)
  print(body)

  title = frontmatter['Title']
  if title.startswith('（移動済）'):
    print(f'Skipped: {title}')
    continue

  print(f'Processing: {title}')

  original_url = frontmatter['URL']
  date: datetime = frontmatter['Date']
  draft = frontmatter.get('Draft', False)

  tags = frontmatter.get('Category')
  category = tags[0] if tags else None

  new_frontmatter = {
    'title': title,
    'date': date.strftime('%Y-%m-%d %H:%M:%S'),
    'draft': draft,
    'channel': '技術ノート',
  }
  if category:
    new_frontmatter['category'] = category
  if tags:
    new_frontmatter['tags'] = tags

  output = yaml.dump(new_frontmatter, default_flow_style=False, sort_keys=False, allow_unicode=True)
  output_lines = output.split('\n')
  output_lines.insert(0, f'---')
  output_lines.insert(1, f'# moved from {original_url}')
  output_lines.insert(-1, f'---')
  output = '\n'.join(output_lines)
  output += f'# {title}\n\n' + body + '\n'

  dest = Path('output', path)
  dest.parent.mkdir(parents=True, exist_ok=True)

  with open(dest, 'w') as fp:
    fp.write(output)

えやみぐさの改修ログ 2022-02-20

Sun, 20 Feb 2022 08:10:00 +0900

えやみぐさ: blog.aoirint.com

えやみぐさのGatsby設定ファイルのTypeScript化

レイアウト用の型定義をgatsby-nodeやgatsby-configで利用するために、これらのGatsby設定ファイルをTypeScript化することになりました。以下の記事が参考になりました。

https://miyauchi.dev/ja/posts/gatsby-typescript/

えやみぐさに「チャンネル」機能を追加

トピックの異なる記事を分離するために、「チャンネル」という単位で記事を分類するようにしました。

これまで、えやみぐさの記事は、カテゴリとタグによって分類していました。しかし、この2つだけでは、例えば日記と技術記事の記事一覧を分離することができません（RSSや最近の記事一覧で問題になる）。えやみぐさに異なるトピック・ジャンルの記事を統合するために、既存のカテゴリとタグによる分類を維持し、新しい階層を加えることにしました。これまでのカテゴリ・タグは、チャンネル別に機能するようにしました。

いまのところ、この記事は作業ログというチャンネルに属しています。通常の技術ノートに比べて、気軽にページを作ることができるようにと考えています。あとで内容の一部を技術ノートに移す・写すこともあるかもしれません。現在の技術ノートはあまり品質がよくない（メモ書きレベル）ので、作業ログに移してもいいかなと思っているのですが、そこそこ記事数があり、中身を確認しながら再分類するのが手間なのでやっていません。作業ログは、作業を中断したり、力尽きたりしたりして、中途半端な内容や矛盾した文章が載っていることがあるかもしれませんが、自分用のメモなので気にしないでいきたいと思っています。

えやみぐさの記事管理方法とURLフォーマットについて

えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。このフォーマットは、えやみぐさの記事をファイルシステム上で管理しやすくするために選んだものです。

えやみぐさの記事を作成するときは、URLと対応したパスにディレクトリを作成し、index.mdファイルを配置します。これは、記事に付随するリソース（画像や音声ファイルなど）と記事本体をまとめて管理するためにそうしています。

比較として、entry/<slug>方式では、ふつうに構成すると1ディレクトリにすべての記事ディレクトリを配置することになります。例えば、2020年には下書きを含めて31件の記事があるのですが、次の年も同じ数の記事を書いたとすると、計62件、その次の年なら計93件になることが予想されます。昔書いた記事に補足を入れたいときや、新しい記事を書きたいときに、100件のサブディレクトリがあるディレクトリを操作するのは、誤操作が起きやすい点、目に入る情報量が多く気が散る点から、望ましくない・苦手です。

entry/<作成年>/<作成月>/<slug>やentry/<作成年>/<作成月>/<作成日>/<slug>も考えられますが、自分の記事作成ペースと、手作業で管理するのが手間に感じる点から採用しませんでした。

えやみぐさのURL永続性について

インターネット上のURLは、永続化することが望ましいという考え方があります。例えば、ブックマークしておいたページが消えていると困りますし、リンクが貼られているとリンク切れを起こしてしまいます。

記事のURLの永続化には、URLの割り当て方法が関わってきます。ブログシステムでのURLの割り当て方法としては、記事タイトルの一部などによる「スラグ」を利用する方法、 DB上の連番IDを利用する方法、時刻や日付を利用する方法、ランダムなIDを利用する方法、が思い付きます。えやみぐさでは、記事のURLをentry/<作成年>/<slug>というフォーマットにしています。

CMS・Wikiなどでは、URLを永続化するためにリダイレクトが自動で貼られる仕組みが用意されている場合がありますが、えやみぐさのコンテンツ管理方式（GitリポジトリにMarkdownファイル）では、リダイレクトによってURLを永続化するのは難しく、実装しても運用するのはそれなりの手間になります（例えば、リダイレクトだけの実体のない記事ページが記事ファイル一覧に含まれる、増え続けるリダイレクトリストの管理など）。

できるだけ記事URLを書き換えないようにしてはいますが、リンクが貼られにくい雑記については、 URL永続性を維持する動機がないので、適当に管理すると思います。

記事のURL名前空間は、チャンネル間で共通にしています（entry/slugのこと）。えやみぐさでは、チャンネル・カテゴリ・タグのようなタクソノミーは、あとで書き換えることがある、という運用を考えています。

えやみぐさの記事一覧について

これまで、えやみぐさのトップページでは、カテゴリの一覧と、各カテゴリの全記事リストを表示する方式をとっていました。これは、過去に書いた技術記事を素早く参照するためのものでした。この記事の執筆時点でも、技術記事用のチャンネル「技術ノート」では、同様の方式で記事一覧を表示するようにしています。

えやみぐさのデプロイ自動化について

えやみぐさを管理するGitリポジトリは、Gatsbyプロジェクトリポジトリと記事リポジトリの2つに分かれています（submoduleで管理しています）。記事の可搬性とレイアウト・記事の分離のためにそうしていますが、固有記法を使うこともあるかもしれませんし、まああまり細かいところは気にしないで運用しています。

えやみぐさのデプロイは、GatsbyプロジェクトリポジトリにpushされたときにはGitHub Actionsが走りますが、記事リポジトリにpushされたときには走りません。

記事を更新したときには、親のGatsbyプロジェクトリポジトリのsubmoduleを更新する手間があります。

Webサイトのレイアウトを調整すること、記事を更新すること、をうまく共存させながら、この手間を解消したいのですが、あんまりいい方法が思い付いていません。。。

例えば、記事を書くときにいちいちGatsbyでレンダリングするのは重くて手間なので、Gatsbyプロジェクトをcloneせずに記事を追加するような運用をしたいと思っていますが、レイアウトをいじるときには実際の記事があった方がいい、というような感じで、どうしたらいいのかなと思っています。

workflow_dispatchをうまく組めば、片方のリポジトリが更新されたときにデプロイ走らせることはできると思うけれど、ローカルで動かすときに微妙な気がしている…

えやみぐさのデプロイにおける「2重コミット問題」を解消した

「2重コミット問題」：テーマリポジトリと記事リポジトリを分離するため、submoduleを使って管理するとき、submoduleと親リポジトリの2つにそれぞれコミットするのが手間になる問題

API経由でWorkflowを実行する。スコープの広いPATが必要なのが難しいところなので、抵抗あったのだけれど、まあ便利なので仕方がない。

MediaWikiのセットアップ

Thu, 03 Feb 2022 07:00:00 +0900

インストール

Docker Hub公式のDockerイメージが公開されている。

Mediawiki - Official Image | Docker Hub

事前準備

docker-compose.yml

version: '3.8'
services:
  mediawiki:
    image: mediawiki:1.37
    restart: always
    ports:
      - '127.0.0.1:8000:80'
    links:
      - database
    volumes:
      - ./app/images:/var/www/html/images
      # After initial setup, download LocalSettings.php to the same directory as
      # this yaml and uncomment the following line and use compose to restart
      # the mediawiki service
      # - ./LocalSettings.php:/var/www/html/LocalSettings.php
      # - ./app/extensions:/var/www/html/extensions
  # This key also defines the name of the database host used during setup instead of the default "localhost"
  database:
    image: mariadb:10.7
    restart: always
    volumes:
      - database-data:/var/lib/mysql
    environment:
      # @see https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/DefaultSettings.php
      MYSQL_DATABASE: my_wiki
      MYSQL_USER: wikiuser
      MYSQL_PASSWORD: example
      MYSQL_RANDOM_ROOT_PASSWORD: 'yes'
volumes:
  database-data:

nginx設定ファイル (/etc/nginx/sites-enabled/wiki.example.com.conf）

server {
    server_name wiki.example.com;

    proxy_set_header HOST $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    # auth_basic "Authentication Required";
    # auth_basic_user_file /path/to/.htpasswd;

    location / {
        proxy_pass http://localhost:8000;
    }
}

手順

docker-compose.yml、nginx設定ファイルを作成
- 必要に応じてsudo certbot --nginxでHTTPS対応
添付ファイルのアップロード先ディレクトリを作成 mkdir -p app/images
docker-compose up -dでMediaWikiを起動
- 起動時にwikiexamplecom_mediawiki_1 is up-to-dateのようなログが表示されるので、isより前のMediaWikiコンテナ名を控える
ブラウザから初期設定
設定ファイルLocalSettings.phpをコピー
- sudo docker cp MediaWikiコンテナ名:/var/www/html/LocalSettings.php ./LocalSettings.php
拡張機能をコピー
- sudo docker cp MediaWikiコンテナ名:/var/www/html/extensions ./app/extensions
docker-compose.ymlを開き、./LocalSettings.php、./app/extensionsのコメントアウトを解除
コンテナを再作成
- sudo docker-compose up -d --force-recreate

拡張機能のインストール

インストール手順

拡張機能の配布ファイル（tar.gz）をサーバにダウンロード
配布ファイルを展開
展開した拡張機能ディレクトリをapp/extensions以下にコピー（app/extensions/Mathのように）
- Dockerコンテナ内では/var/www/html/extensions/Mathのように配置される
LocalSettings.phpにwfLoadExtension( '拡張機能ディレクトリ名' );のように追記
- wfLoadExtension( 'Math' );
- wfLoadExtension( 'SyntaxHighlight_GeSHi' );
「メンテナンス：再起動」を実行
「メンテナンス：データベース構造の更新」を実行

数式（Math）

シンタックスハイライト（SyntaxHighlight）

設定

ロゴを変更

ロゴ変更 LocalSettings.php

## The URL paths to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
#$wgLogos = [ '1x' => "$wgResourceBasePath/resources/assets/wiki.png" ];
$wgLogos = [ '1x' => "$wgResourceBasePath/images/logo.png" ];

ロゴ変更手順

LocalSettings.phpを編集
ロゴ画像をapp/images/logo.pngに配置
「メンテナンス：再起動」を実行

既定のタイムゾーンを変更

Manual:Timezone - MediaWiki

タイムゾーン変更 LocalSettings.php

# Time zone
#$wgLocaltimezone = "UTC";
$wgLocaltimezone = "Asia/Tokyo";

タイムゾーン変更手順

LocalSettings.phpを編集
「メンテナンス：再起動」を実行

メンテナンス

再起動

sudo docker-compose up -d --force-recreate

データベース構造の更新

Manual:update.php - MediaWiki

sudo docker-compose exec -u 1000 mediawiki php maintenance/update.php

Hexo

Wed, 17 Nov 2021 04:00:00 +0900

https://hexo.io/docs/#Installation

npm install -g hexo-cli

$ hexo help
Usage: hexo <command>

Commands:
  help     Get help on a command.
  init     Create a new Hexo folder.
  version  Display version information.

Global Options:
  --config  Specify config file instead of using _config.yml
  --cwd     Specify the CWD
  --debug   Display all verbose messages in the terminal
  --draft   Display draft posts
  --safe    Disable all plugins and scripts
  --silent  Hide output on console

For more help, you can use 'hexo help [command]' for the detailed information
or you can check the docs: http://hexo.io/docs/

hexo init <folder>は空のディレクトリに対して実行する必要がある。いったん仮のディレクトリを作ってからコピーする。.github、.gitignoreファイルがあるのでコピー忘れに注意。

WordPress

Sat, 13 Nov 2021 13:00:00 +0900

https://hub.docker.com/_/wordpress

docker-compose.yml

version: "3.9"

services:
  wordpress:
    image: wordpress:5.8.2-apache
    restart: always
    ports:
      - "${SERVER_PORT}:80"
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: wordpress
      WORDPRESS_DB_PASSWORD: wordpress
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wordpress:/var/www/html

  db:
    image: mariadb:10.7
    restart: always
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wordpress
      MYSQL_PASSWORD: wordpress
      MYSQL_RANDOM_ROOT_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  wordpress:
  db:

.env

SERVER_PORT=127.0.0.1:8000

Wiki.jsのセットアップ

Tue, 01 Jun 2021 05:00:00 +0900

メモリ消費量

$ docker stats
CONTAINER ID   NAME            CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O         PIDS
e225b6b77209   wikijs_wiki_1   0.01%     127.6MiB / 7.681GiB   1.62%     13.1MB / 22.7MB   44.5MB / 1.45MB   11
13d085313406   wikijs_db_1     0.00%     44.57MiB / 7.681GiB   0.57%     6.64MB / 4.09MB   4.27MB / 102MB    8

初期状態で150-200MiB程度の消費量と思われる。

下記の環境をサーバとして、別端末からNATループバックによる接続を試したところ、ページ遷移時のロードや記事の保存に少しだけ時間がかかるように思われたが、Wikiサイト自体がなかなか開かない、というような重さではなかった。

CPU: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz
Memory: 8GB
Storage: SSD
OS: Ubuntu Desktop 18.04

docker-compose.yaml

version: "3.9"
services:
  db:
    image: postgres:13-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data

  wiki:
    image: requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:3000"

volumes:
  db-data:

基本的に初期設定で問題ない。

Sphinx

Tue, 05 Jan 2021 07:40:00 +0900

Python製のドキュメント生成ツール。

Python 3.8.5
Sphinx 3.4.2
- Sphinx · PyPI

pip3 install Sphinx

reST（reStructuredText）

SphinxではデフォルトでreStructuredTextというマークアップ言語を使う。

既存Pythonプロジェクトにドキュメントを追加する

setup.py などが存在するPyPIパッケージプロジェクトを想定する。

プロジェクトのルートに docs ディレクトリを作成し、インタラクティブツール sphinx-quickstart を実行する。

mkdir docs
cd docs/
sphinx-quickstart

Separate source and build directories (y/n) と聞かれるので、 y 。プロジェクト名、著者名、言語などを答える。

source ディレクトリ、 build ディレクトリ、 Makefile が生成される。

make html

以上のコマンドで build/html ディレクトリにHTMLが生成される。

python3 -m http.server -b localhost -d build/html

などで確認する。

次はPythonモジュールのdocstringからドキュメントを自動生成する。

#!/bin/bash

SCRIPT_DIR=$(cd $(dirname $0); pwd)

cd "${SCRIPT_DIR}"
sphinx-apidoc -f -o "./source/api" "../mymodule"

make html

docs/mkdocs.sh を以上のように作成し、実行する（TODO：Makefileへの入れ込み）。ここでは、以下のように docs ディレクトリと並んで、パッケージとして提供するPythonモジュール mymodule のディレクトリがあることを想定している。なお、 docs/source/conf.py は設定ファイルであり、例えば html_theme = 'sphinx_rtd_theme' のような設定を追加し、 pip3 install sphinx-rtd-theme してから make html することで、Read the Docsスタイルのドキュメントを生成できる。

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

Wed, 09 Sep 2020 09:48:39 +0900

概要

新しく静的サイトジェネレータでブログ環境を整備した。細かい使い方には触れないが、構成を書いておく。

静的サイトジェネレータとCI/CD

静的サイトジェネレータ

静的サイトジェネレータというのはSphinx（Python製）とかJekyll（Ruby製、GitHub Pages標準らしい）とかHugo（Go製）みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。

Miyadaiku

MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント（とサンプルテンプレート、ソースコード）を見ていくしかないかも。

GitHub Actions

GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、つまりCI（Continuos Integration、テストやビルドの自動化）/CD（Continuous Delivery、デプロイの自動化）を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで（手元にリポジトリがあっても）GitHub ActionsによるCI/CDができないのが難点な気がする。

GitHub Status

考えていること

レンダリング後のHTMLファイルの分離

Markdownを書いている時に見えるところに（レンダリング後の）HTMLファイルを置きたくない。できれば何も考えずに（Markdownで書いた）メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して（オプションで指定したテーマなどで）いい感じにレンダリングしてくれるようなものがいい（HTMLファイル自体にファイルシステムからアクセスできる必要はない）と思っていた。

このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性（再レンダリングしても差分がない状態）が崩れてしまうことがない。それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、（見える）commitに含めたくない気持ちがある。

この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ（gh-pages）に自動でcommitされるように設定する。

GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ（gh-pagesブランチの更新）にはgithub:peaceiris/actions-gh-pagesを使っている。

# deploy.yml
name: Deploy

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
      - uses: actions/checkout@v2

      - name: Setup Python
        uses: actions/setup-python@v2
        with:
          # Version range or exact version of a Python version to use, using SemVer's version range syntax.
          python-version: 3.x

      - name: Install dependencies
        run: pip3 install -r requirements.txt

      - name: Run miyadaiku-build
        run: miyadaiku-build --output public .

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./public

name、runのところをコピーして増やせばコマンドを増やすことができる。

ブログ on えやみぐさ

えやみぐさの記事運用 2022-06-24

はてなブログから古い記事を移した

えやみぐさの改修ログ 2022-02-20

えやみぐさのGatsby設定ファイルのTypeScript化

えやみぐさに「チャンネル」機能を追加

えやみぐさの記事管理方法とURLフォーマットについて

えやみぐさのURL永続性について

えやみぐさの記事一覧について

えやみぐさのデプロイ自動化について

えやみぐさのデプロイにおける「2重コミット問題」を解消した

MediaWikiのセットアップ

インストール

事前準備

docker-compose.yml

nginx設定ファイル (/etc/nginx/sites-enabled/wiki.example.com.conf）

手順

拡張機能のインストール

インストール手順

数式（Math）

シンタックスハイライト（SyntaxHighlight）

設定

ロゴを変更

ロゴ変更 LocalSettings.php

ロゴ変更 手順

既定のタイムゾーンを変更

タイムゾーン変更 LocalSettings.php

タイムゾーン変更 手順

メンテナンス

再起動

データベース構造の更新

Hexo

WordPress

docker-compose.yml

.env

Wiki.jsのセットアップ

メモリ消費量

docker-compose.yaml

Sphinx

reST（reStructuredText）

既存Pythonプロジェクトにドキュメントを追加する

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

概要

静的サイトジェネレータとCI/CD

静的サイトジェネレータ

Miyadaiku

GitHub Actions

考えていること

レンダリング後のHTMLファイルの分離

ロゴ変更手順

タイムゾーン変更手順