ホーム 記事一覧 ブック DH週間トピックス 検索 このサイトについて
English
Claude Codeで6件のGitHub Issueを並行対応:worktreeとagentの活用

Claude Codeで6件のGitHub Issueを並行対応:worktreeとagentの活用

はじめに TEI/XMLで構造化された歴史史料をWeb上で閲覧できるビューアを、Nuxt 2 + Vue 2 + Vuetifyで開発しています。このプロジェクトに報告された6件のGitHub Issueに対して、Claude Codeのworktree機能とagentを活用して並行対応した記録を紹介します。 対応したIssue一覧 グループ Issue数 内容 優先度 A 3件 テキストビューワの入れ子要素の表示不具合 高 B 1件 凡例ページのインデント未反映 中 C 1件 分析ページのリンク切れ 高 D 1件 キーワード検索のクラッシュ 高 アプローチ:worktree × 並行agent Claude Codeには、git worktreeを使って独立した作業環境で複数のagentを並行実行する機能があります。今回は上記4グループに対して、4つのagentを同時に起動しました。 各agentがworktreeで独立して作業するため、互いに干渉せず並行して修正を進められます。 Agent 1: fix/nested-tags → グループA(3件、同一の根本原因) Agent 2: fix/legend-indent → グループB Agent 3: fix/analytics-links → グループC Agent 4: fix/keyword-search → グループD 各Issueの修正内容 グループD:検索プラグインのクラッシュ 原因: 検索プラグイン内で、環境変数から読み込む設定値がundefinedのため、検索実行時にTypeErrorでクラッシュしていました。 修正: 1行のnullガード追加で解決しました。最もシンプルな修正でしたが、agentが原因を正確に特定してくれました。 グループA:入れ子要素の表示不具合 3件のIssueは一見別々の問題に見えましたが、すべて共通の根本原因を持っていました。 原因: TEI XMLの前処理スクリプトが、入れ子構造の要素を正しく変換していませんでした。具体的には、テキスト範囲を示すアンカーペアを要素に変換する処理で、入れ子になった内側の要素がフィルタリングで除外されていたため、テキストやクリック可能な注釈が失われていました。 修正: 前処理スクリプトに3つの変更を加えました。 ...

Drupal の GitHub Webhook モジュールを改善しました。

Drupal の GitHub Webhook モジュールを改善しました。

Drupal の管理画面から GitHub Actions をトリガーするカスタムモジュール「GitHub Webhook」を改善しました。 https://github.com/nakamura196/Drupal-module-github_webhook 元は複数リポジトリ対応の基本的なモジュールでしたが、UI のタブ分離、権限の細分化、ワークフローステータス表示、自動トリガーなどの機能を追加しています。 改善前のモジュール 元のモジュールは、以下のような構成でした。 ファイル数 : 5ファイル(info.yml、routing.yml、links.menu.yml、permissions.yml、SettingsForm.php) 対応バージョン : Drupal 10 のみ リポジトリ : 複数対応済み(AJAX で動的追加・削除) 画面 : 設定とトリガーが同一画面(アコーディオン2つ) 権限 : access github webhook settings の1権限のみ(設定もトリガーも同じ権限) トークン管理 : パスワードフィールドに #default_value を設定(HTML ソースに平文で出力される) HTTP クライアント : new \GuzzleHttp\Client() を直接インスタンス化 例外クラス : use 文なしで catch ブロックに記述(名前空間の解決が不正) // 改善前: トークンが #default_value に設定されていた $form['settings']['github_token'] = [ '#type' => 'password', '#title' => $this->t('GitHub Token'), '#default_value' => $config->get('github_token'), // HTML に平文出力される ]; // 改善前: Guzzle クライアントを直接 new していた $client = new \GuzzleHttp\Client(); 変更の全体像 改善前後のファイル構成の比較です。* は変更、+ は新規追加を示します。 ...

Docker + GitHub Actions デプロイ設定

Docker + GitHub Actions デプロイ設定

このドキュメントでは、Docker コンテナを GitHub Actions で自動デプロイする設定手順を説明します。 目次 Docker 設定 GitHub Actions 設定 サーバー側の設定 トラブルシューティング Docker 設定 Dockerfile(静的サイト + nginx) 静的 HTML を生成し、nginx で配信します。 FROM node:22-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run generate # 静的ファイル配信用のnginx FROM nginx:alpine # Nuxt 3 の場合: .output/public # Nuxt 2 の場合: dist COPY --from=builder /app/.output/public /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] nginx.conf(SPA 用設定) SPA では動的ルート(/item/:id など)を index.html にフォールバックさせる必要があります。 ...

Odeuropa Explorer の語彙階層構造を調査する

Odeuropa Explorer の語彙階層構造を調査する

はじめに Odeuropa Explorer は、ヨーロッパの嗅覚遺産をデジタル化した興味深いプロジェクトです。EU の Horizon 2020 研究プログラムの助成を受け、歴史的な匂いの体験を横断的に検索・探索できるプラットフォームを提供しています。 このプロジェクトでは、匂いに関連する情報を以下の3つの主要なカテゴリで分類しています: Smell sources : 匂いを発する物体や物質 Fragrant Spaces : 匂いに関連する場所や空間 Gestures and Allegories : 匂いに関する身振りや寓意的表現 本記事では、これらの語彙がどのような階層構造を持っているのか、Odeuropa vocabularies リポジトリで公開されている SKOS(Simple Knowledge Organization System)形式のデータを調査した結果を報告します。 調査方法 SKOS階層の可視化スクリプト 語彙の階層構造を理解するために、Node.js で SKOS Turtle ファイルを解析するスクリプトを作成しました。 import $rdf from 'rdflib'; import fs from 'fs'; const SKOS = $rdf.Namespace('http://www.w3.org/2004/02/skos/core#'); async function visualizeHierarchy(ttlFile) { const store = $rdf.graph(); const data = fs.readFileSync(ttlFile, 'utf8'); $rdf.parse(data, store, 'http://example.org/', 'text/turtle'); // Get all concepts const concepts = store.match(null, $rdf.sym('http://www.w3.org/1999/02/22-rdf-syntax-ns#type'), SKOS('Concept')); // Build maps for broader/narrower relationships const broaderMap = new Map(); const narrowerMap = new Map(); const conceptLabels = new Map(); for (const concept of concepts) { const subject = concept.subject; // Get prefLabel const labels = store.match(subject, SKOS('prefLabel'), null); if (labels.length > 0) { conceptLabels.set(subject.value, labels[0].object.value); } // Get broader concepts const broaders = store.match(subject, SKOS('broader'), null); if (broaders.length > 0) { const broader = broaders[0].object.value; broaderMap.set(subject.value, broader); if (!narrowerMap.has(broader)) { narrowerMap.set(broader, []); } narrowerMap.get(broader).push(subject.value); } } // Print hierarchy recursively function printHierarchy(conceptUri, indent = '', visited = new Set()) { if (visited.has(conceptUri)) return; visited.add(conceptUri); const label = conceptLabels.get(conceptUri); const children = narrowerMap.get(conceptUri) || []; console.log(`${indent}${label}`); children.forEach((child, index) => { const isLast = index === children.length - 1; const prefix = isLast ? '└── ' : '├── '; printHierarchy(child, indent + prefix, new Set(visited)); }); } // Find and display top-level concepts const topLevelConcepts = []; for (const concept of concepts) { if (!broaderMap.has(concept.subject.value)) { topLevelConcepts.push(concept.subject.value); } } topLevelConcepts.forEach(concept => printHierarchy(concept)); } このスクリプトの主要な処理: ...

TEI/XMLファイルをGitHubで公開する手順書

TEI/XMLファイルをGitHubで公開する手順書

はじめに この記事では、TEI(Text Encoding Initiative)形式のXMLファイルをGitHubにアップロードし、誰でも参照できるURLを作成する手順を説明します。 TEI/XMLは、歴史文献や文学作品などのテキストを構造的に記述するための国際標準形式です。GitHubを使うことで、あなたの研究データを世界中の研究者と共有できるようになります。 必要なもの パソコン(Windows、Mac、Linuxのいずれか) インターネット接続 TEI/XMLファイル(すでにお持ちのもの) メールアドレス(GitHubアカウント作成用) サンプルファイルについて TEI/XMLファイルをお持ちでない方は、以下の『校異源氏物語』のTEI/XMLファイルを練習用として使用できます: サンプルファイルURL : https://raw.githubusercontent.com/kouigenjimonogatari/kouigenjimonogatari.github.io/master/tei/01.xml このファイルをダウンロードする方法: 上記URLをブラウザで開く 右クリック→「名前を付けて保存」を選択 ファイル名を「koukin_genji_01.xml」などに設定して保存 ステップ1:GitHubアカウントの作成 1-1. GitHubのウェブサイトにアクセス ブラウザ(Chrome、Firefox、Safari等)を開きます アドレスバーに https://github.com と入力してEnterキーを押します 1-2. アカウント作成 右上の「Sign up」ボタンをクリックします 以下の情報を入力します: メールアドレス :普段お使いのメールアドレス パスワード :安全なパスワード(8文字以上、数字と記号を含む) ユーザー名 :他の人と重複しない名前(例:yamada-taro2024) 「Create account」をクリックします メールに届いた認証コードを入力します 💡 ヒント : ユーザー名は後から変更できないので、慎重に選びましょう。研究者として使う場合は、実名に基づいた名前がおすすめです。 ステップ2:新しいリポジトリの作成 リポジトリとは、ファイルを保管する「プロジェクトフォルダ」のようなものです。 2-1. リポジトリ作成画面へ GitHubにログインした状態で、右上の「+」マークをクリックします 「New repository」を選択します 2-2. リポジトリの設定 以下の項目を入力・選択します: Repository name(リポジトリ名) 英数字とハイフン(-)が使えます 例:tei-xml-collection、medieval-texts-tei Description(説明)※任意 プロジェクトの簡単な説明 例:「中世文献のTEI/XMLファイル集」 Public/Private(公開設定) Public を選択:誰でも閲覧可能(推奨) Private:招待した人のみ閲覧可能 Initialize this repository with:(初期化オプション) ✅ Add a README file にチェックを入れる その他はそのままで大丈夫です 緑色の「Create repository」ボタンをクリックします ステップ3:TEI/XMLファイルのアップロード 3-1. アップロード画面へ リポジトリが作成されると、ファイル一覧画面が表示されます 「Add file」ボタンをクリックします 「Upload files」を選択します 3-2. ファイルのアップロード 方法A:ドラッグ&ドロップ エクスプローラー(Windows)またはFinder(Mac)でTEI/XMLファイルがある場所を開きます アップロードしたいファイルを選択します(複数選択可) ブラウザの点線枠内にドラッグ&ドロップします 方法B:ファイル選択 「choose your files」をクリックします ファイル選択ダイアログでTEI/XMLファイルを選択します 「開く」をクリックします 実例:『校異源氏物語』のTEI/XMLファイルをアップロード サンプルファイルを使った具体例: ...

GitHub File History Analyzerの紹介:ファイル編集履歴をAIで分析するツール

GitHub File History Analyzerの紹介:ファイル編集履歴をAIで分析するツール

本記事はAIが作成しました。 はじめに GitHubリポジトリで管理されているファイルの編集履歴を分析したいと思ったことはありませんか?特に長期間にわたって更新されているファイルの変更パターンや、プロジェクトの進化の過程を理解したい場合があります。 GitHub File History Analyzerは、このようなニーズに応えるために開発したコマンドラインツールです。 ツールの概要 このツールは以下の機能を提供します: GitHubのAPIを使用して特定ファイルのコミット履歴を取得 変更内容の統計的な分析(追加・削除行数、変更タイプの分類など) OpenRouter経由でAI(Gemini 2.5 Proなど)による編集パターンの分析 分析結果のMarkdown/JSON形式での出力 開発の背景 デジタルアーカイブプロジェクトで、XMLファイルの長期的な編集作業を追跡する必要がありました。単純なgit logでは得られない、より深い洞察(編集の傾向、作業の質、進捗状況など)を得たいという要求から、このツールの開発に至りました。 技術的な実装 使用技術 言語 : Python 3.8+ 主要ライブラリ : PyGithub(GitHub API wrapper) requests(HTTP通信) python-dotenv(環境変数管理) アーキテクチャ ツールは主に2つのコンポーネントで構成されています: GitHubFileHistoryAnalyzer : GitHub APIを使用してファイル履歴を取得・分析 OpenRouterClient : AI分析のためのクライアント # 基本的な使用例 analyzer = GitHubFileHistoryAnalyzer(github_token) commits = analyzer.get_file_history("owner/repo", "path/to/file.xml") analysis = analyzer.analyze_patches(commits) prompt = analyzer.generate_ai_prompt(commits, analysis) 実際の使用例 基本的なコマンド # ファイル履歴の取得と表示 python main.py --repo owner/repo --file path/to/file.py # AI分析の実行 python main.py --repo owner/repo --file path/to/file.py --analyze # 結果をMarkdown形式で保存 python main.py --analyze --ai-output analysis.md 分析結果の例 ツールは以下のような情報を提供します: ...

Omeka S: Advanced Searchモジュールに対応したテーマを探す

Omeka S: Advanced Searchモジュールに対応したテーマを探す

概要 Omeka SのAdvanced Searchモジュールに対応したテーマを探す方法の一例について紹介します。 背景 Omeka SのAdvanced Searchモジュールを用いることで、以下の記事などで紹介しているように、Omeka Sの検索画面をカスタマイズすることができます。 特に、ファセットなどを追加できる点に利点があります。 一方、使用しているテーマがこのAdvanced Searchモジュールに対応していない場合、一部表示が崩れてしまうケースがあります。テーマ側でAdvanced Searchモジュールに対応しているかどうかを判断する方法の一例として、以下のように、テーマのフォルダの「view/common」の下に「advanced-search」の有無を確認する方法があります。 https://github.com/omeka-s-themes/freedom/tree/master/view/common/advanced-search この方法に基づいて、GitHubで公開されているOmeka Sのテーマのうち、Advanced Searchモジュールに対応しているものを探す方法を紹介します。 方法 以下の記事で紹介したサイトを使用します。 URLは以下です。 https://satoru196.notion.site/satoru196/6f898ed1352e4c9fa013eee635cbabf4?v=02cab757b6cf4df6bfbedfeb85eca0a5 特に、本記事の目的のため、「各テーマがAdvanced Searchモジュールに対応しているか」のフラグを追加しました。加えて、リポジトリのownerの情報も加え、各テーマが誰によって提供されているかを確認できるようにしました。 具体的には、以下の図に示すように、スター数で降順として、さらに「has_advanced_search」にチェックが入っているテーマのみに限定します。 この結果、「freedom」というテーマが「omeka-s-themes」というOmekaの公式Teamによって提供されており、相対的にスター数が多く、Advanced Searchモジュールにも対応していることがわかります。 https://github.com/omeka-s-themes/freedom まとめ Omeka Sのテーマの探し方の一例について紹介しました。Omeka Sの利用にあたり、参考になりましたら幸いです。

DrupalからGitHubのActionsを実行するモジュールを作成しました。

DrupalからGitHubのActionsを実行するモジュールを作成しました。

概要 DrupalからGitHubのActionsを実行するモジュールを作成しました。 https://github.com/nakamura196/Drupal-module-github_webhook 以下、使い方について説明します。 使い方 設定 モジュールのインストール後、以下にアクセスします。 /admin/config/github_webhook 以下のような画面に遷移します。 大きく、Respositories とTrigger Webhook に分かれています。 まず、Respositories のRepository 1にGitHub Actionsの実行対象のリポジトリの情報を入力します。Add repositoryやRemove repositoryから、リポジトリの追加と削除を行うことができます。 Event Typeには、GitHub Actions側で設定した値を入力します。初期値のwebhookは、以下のようなActionsを想定しています。 name: Deploy to GitHub Pages on: push: branches: ["main"] workflow_dispatch: repository_dispatch: types: [webhook] permissions: contents: read pages: write id-token: write concurrency: group: "pages" cancel-in-progress: true jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v3 ... 設定後、画面下部の送信 ボタンを押して保存します。 ...

Drupalのイベントをトリガーとして、GitHub Actionsを起動する

Drupalのイベントをトリガーとして、GitHub Actionsを起動する

概要 Drupalのイベントをトリガーとして、GitHub Actionsを起動する方法の備忘録です。 以下のサイトが参考になりました。 https://qiita.com/hmaruyama/items/3d47efde4720d357a39e pipedreamの設定 triggerとcustom_requestを含むワークフローを作成します。 triggerについては、以下を参考にしてください。 https://qiita.com/hmaruyama/items/3d47efde4720d357a39e#pipedream側の設定 custom_requestにおいて、dispatchに関する設定を行います。 https://docs.github.com/ja/rest/repos/repos?apiVersion=2022-11-28#create-a-repository-dispatch-event 以下のような設定を行います。 curl -L \ -X POST \ -H "Accept: application/vnd.github+json" \ -H "Authorization: Bearer <YOUR-TOKEN>" \ -H "X-GitHub-Api-Version: 2022-11-28" \ https://api.github.com/repos/OWNER/REPO/dispatches \ -d '{"event_type":"webhook"}' Drupalの設定 以下のモジュールをインストールします。 https://www.drupal.org/project/webhooks インストール後、以下のページで設定を行います。 /admin/config/services/webhook GitHub Actionsの設定 以下のようにrepository_dispatchを設定します。これにより、pipedreamからのリクエストに基づき、GitHub Actionsが実行されます。 name: Build and Deploy to Production on: push: branches: - main # Allows external webhook trigger repository_dispatch: types: - webhook permissions: contents: read concurrency: group: "build-and-deploy" cancel-in-progress: true jobs: ... まとめ pipedreamを使用せずに、Drupalのカスタムモジュールを作成することにより、GitHubに通知を送る方法もありそうです。(すでにそのようなモジュールが開発されている可能性が高そうですが、見つけることができませんでした。) ...

GitHub ActionsとSCPを使って、さくらのレンタルサーバにビルド結果をコピーする

GitHub ActionsとSCPを使って、さくらのレンタルサーバにビルド結果をコピーする

概要 GitHub ActionsとSCPを使って、さくらのレンタルサーバにビルド結果をコピーする機会がありましたので、その備忘録です。 以下のGitHub Actionsを使用しました。 https://github.com/appleboy/scp-action つまづいた点 以下の記法で試みたところ、ローカル環境でactを使った際にはうまく動作しましたが、GitHub Actionsで実行した際にはうまくいきませんでした。 name: scp files on: [push] jobs: build: name: Build runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: copy file via ssh password uses: appleboy/scp-action@master with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} password: ${{ secrets.PASSWORD }} port: ${{ secrets.PORT }} source: "tests/a.txt,tests/b.txt" target: your_server_target_folder_path 具体的には、以下のエラーが発生しました。 GitHub actions workflow error: ssh: handshake failed: ssh: unable to authenticate, attempted methods [none password], no supported methods remain こちらについて以下が参考になりました。 ...

GitHub Actionsの処理結果をメールで通知する: Gmailの使用

GitHub Actionsの処理結果をメールで通知する: Gmailの使用

概要 GitHub Actionsの処理結果をメールで通知する機会がありましたので、その備忘録です。 今回はGmailを使います。以下が参考になりました。 https://stackoverflow.com/questions/69947109/sending-email-with-github-actions Gmailの設定 以下に記載があります。2段階認証を有効にして、アプリパスワードを作成します。 https://github.com/dawidd6/action-send-mail?tab=readme-ov-file#gmail アプリパスワードの設定例は以下です。 ローカルでの動作確認 actを使って、ローカル環境でGitHub Actionsを実行します。 https://github.com/nektos/act あるリポジトリで以下のようなファイルを作成します。 name: Notification Workflow on: [push] jobs: send-mail: runs-on: ubuntu-latest steps: - name: Send mail if: success() # この行はデプロイが成功した場合にのみメールを送信するようにします uses: dawidd6/action-send-mail@v3 with: server_address: smtp.gmail.com server_port: 465 username: ${{secrets.MAIL_USERNAME}} password: ${{secrets.MAIL_PASSWORD}} subject: Deployment Completed - ${{ github.repository }} to: ${{secrets.MAIL_TO}} from: ${{ secrets.MAIL_FROM }} body: | Hello, The deployment process for the repository ${{ github.repository }} has been successfully completed. Commit: ${{ github.sha }} Commit link: https://github.com/${{ github.repository }}/commit/${{ github.sha }} Branch: ${{ github.ref }} Best regards, ${{ secrets.MAIL_FROM }} 以下のようなコマンドでシークレットを使うことができました。 ...

GitHubのリポジトリをZenodoと連携する

GitHubのリポジトリをZenodoと連携する

概要 先日、Mirador3でアノテーションを比較するためのプラグインを公開しました。 https://github.com/nakamura196/mirador-compare-plugin 今回は、このリポジトリをZenodoと接続してみます。 結果、releaseを行うたびに、自動的にDOIが付与されるようになりました。 https://zenodo.org/doi/10.5281/zenodo.10449856 Zenodoでの設定 以下にアクセスして、連携対象のGitHubリポジトリを選択します。 /account/settings/github/ GitHub 以下、必須ではありませんが、Zenodoとの連携に向けて、GitHubリポジトリ上で必要な準備を行います。 CITATION.cffの作成 これを作成することにより、Creators にORCIDのIDが表示されるようでした。 具体的には、以下のようなファイルを作成します。 https://github.com/nakamura196/mirador-compare-plugin/blob/main/CITATION.cff cff-version: 1.1.0 message: "Cite as" authors: - family-names: Nakamura given-names: Satoru orcid: https://orcid.org/0000-0001-8245-7925 affiliation: "The University of Tokyo" website: https://researchmap.jp/nakamura.satoru?lang=en title: "mirador-compare-plugin" doi: 10.5281/zenodo.10449856 上記により、GitHubリポジトリ上にも「Cite this repository」が表示されるようになりました。 バッジの表示 以下が参考になりました。 https://gist.github.com/seignovert/ae6771f400ca464d294261f42900823a 以下のURLにアクセスして、idを取得します。今回は、664611010でした。 https://api.github.com/repos/nakamura196/mirador-compare-plugin このidを使用して、README.mdに以下を追加します。 [![DOI](https://zenodo.org/badge/664611010.svg)](https://zenodo.org/badge/latestdoi/664611010) 結果、以下のようにバッジが表示されました。 READEME.mdへのCite asの追加 ResearchObject/ro-crate-py を参考に、READEME.mdへCite asを追加してみます。 この時、以下に記載があるIDを用いることで、最新のバージョンに遷移するURLを作成することができました。 具体的には、今回は10449856というIDを使って、READMEに追記する内容を作成しました。 [![DOI](https://zenodo.org/badge/664611010.svg)](https://zenodo.org/badge/latestdoi/664611010) The above DOI corresponds to the latest versioned release as [published to Zenodo](https://zenodo.org/records/10449856), where you will find all earlier releases. To cite `mirador-compare-plugin` independent of version, use https://doi.org/10.5281/zenodo.10449856, which will always redirect to the latest release. リリースの作成 プルリクエストとマージ ブランチの作成 ...

DrupalのSocial Auth GitHubモジュールを試す

DrupalのSocial Auth GitHubモジュールを試す

概要 DrupalのSocial Auth GitHubモジュールを試します。 https://www.drupal.org/project/social_auth_github/ 本モジュールは以下のように説明されています。 Social Auth GitHub allows users to register and login to your Drupal site with their GitHub account. (日本語訳)Social Auth GitHubは、ユーザーがGitHubアカウントを使用してDrupalサイトに登録およびログインすることを可能にします。 以下のように、GitHubアカウントを使用してログインできるようにすることを目指します。 インストール composer.phar require 'drupal/social_auth_github:^4.0' vendor/bin/drush en social_auth_github 上記のインストールにより、social_authとsocial_apiも有効化されます。 設定 以下のページを参考に設定を進めます。 https://www.drupal.org/project/social_auth_github/ Drupal 以下にアクセス /admin/config/social-api/social-auth さらに、以下にアクセス /admin/config/social-api/social-auth/github Authorized redirect URLの値をコピーしておきます。 GitHub OAuth Appsを作成します。以下のような入力を行います。 Drupal 以下に戻り、Client IDやClient secretを入力します。 /admin/config/social-api/social-auth/github この結果、/user/login/githubにアクセスすると、GitHubのログイン画面が表示され、成功すると、Post login pathで指定したページに戻ります。 (参考)ブロックの追加 以下のように、ログイン画面にGitHubへのログインブロックを設置してみます。 /admin/structure/blockにアクセスし、「ブロックを配置」を押します。 「Social Auth Login」の「ブロックを配置」を押します。 ...

ブラウザの拡張機能を使って、GitHubの2FAに対応する

ブラウザの拡張機能を使って、GitHubの2FAに対応する

概要 GitHubの2要素認証(2FA)への対応にあたり、ブラウザの拡張機能である「Authenticator」を使用してみましたので、その備忘録です。 https://authenticator.cc/ QRコードの準備 まず、GitHub側でQRコードを準備します。詳細な手順は省きますが、以下のような画面にQRコードが表示されます。 ブラウザ拡張機能の追加 Chrome、Firefox、Edgeのいずれかのブラウザで以下にアクセスします。以下、Chromeの例です。 https://authenticator.cc/ 以下の画面の「Add to XXXX」ボタンを押します。 「Chromeに追加」ボタンを押します。 以下の画面が表示されれば成功です。 アカウントの追加 先ほど用意したQRコードをブラウザで表示します。以下は、Googleドライブに保存したQRコードの画像を表示している画面例です。 右上の「拡張機能」ボタンを押して、「Authenticator」をクリックします。 スキャンのアイコンをクリックします。 表示しているQRコードの範囲を選択すると、「<アカウント名> 追加されました。」と表示されます。 以後、2FAが求められた場合、拡張機能を選択して、「Authenticator」をクリックします。 以下のようにOne-Time Password (OTP)が表示されるので、パスワードをコピーして使用します。 バックアップファイルの利用 バックアップファイルを作成して、それを他の端末やブラウザでインポートして使用することもできるようです。 バックアップファイルの作成 拡張機能の設定画面から、「バックアップ」を選択します。 そして、「バックアップファイルのダウンロード」を押します。 「authenticator.txt」というファイルがダウンロードされますので、本ファイルまたは本ファイルの中の文字列を他者と共有します。 バックアップファイルのインポート インポートする際には、先の設定 > バックアップ の後に、「バックアップのインポート」を選択します。 そして、以下の画面において、「バックアップファイルのインポート」タブを選択して、txtファイルをアップロードするか、「テキストのバックアップのインポート」を選択して、txtファイルの中身のテキストを貼り付けてインポートします。 結果、アカウントが登録されます。 まとめ 参考になりましたら幸いです。

Github Actionsを使ってGithubからEC2までのDjangoのCICD環境構築(2023版)

Github Actionsを使ってGithubからEC2までのDjangoのCICD環境構築(2023版)

概要 Github Actionsを使ってGithubからEC2までのDjangoのCICD環境を構築する機会があり、その備忘録です。 以下の記事を参考にさせていただきました。 https://qiita.com/fffukken/items/27b0bfa712940914d3f6 上記の記事に対して、Github Actionsの設定を一部更新しました。 Github Actionsの設定 name: Test and Deploy on: push: branches: [ develop, main ] pull_request: branches: [ develop ] jobs: build: runs-on: ubuntu-latest strategy: max-parallel: 4 matrix: python-version: [3.9, "3.10"] steps: - uses: actions/checkout@v3 - name: Set up Python ${{ matrix.python-version }} uses: actions/setup-python@v4 with: python-version: ${{ matrix.python-version }} - name: Install Dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt - name: Run Tests run: | python manage.py makemigrations python manage.py migrate python manage.py test - name: deploy run: | echo "$SECRET_KEY" > secret_key chmod 600 secret_key ssh -oStrictHostKeyChecking=no ${EC2_USER}@${EC2_HOST} -i secret_key "source <仮想環境名>/bin/activate \ && cd ~/<プロジェクト名>\ && git pull origin main \ && python manage.py makemigrations \ && python manage.py migrate \ && deactivate \ && sudo systemctl restart gunicorn" env: SECRET_KEY: ${{ secrets.SECRET_KEY }} EC2_USER: ${{ secrets.EC2_USER }} EC2_HOST: ${{ secrets.EC2_HOST }} 変更した点として、actions/checkoutとactions/setup-pythonのバージョンを変更しました。また、pip installの部分を変更し、pip install -r requirements.txtにしました。 ...

GitHubのGUIを使ったファイルアップロードおよびファイル更新の方法について

GitHubのGUIを使ったファイルアップロードおよびファイル更新の方法について

概要 GitHubファイルアップロードおよびファイル更新の方法について共有する機会がありました。 ログイン アカウントの新規作成を含めて、以下の記事などを参考にしてください。 https://reffect.co.jp/html/create_github_account_first_time ファイルアップロード リポジトリにアクセスします。 Add fileボタンをクリックして、Upload filesをクリックします。 choose your filesをクリックして、ローカルからファイルをアップロードして、Commit changesを押します。 ファイルがアップロードされます。同じ名前のファイルが既に存在する場合には、上書き更新されます。 ファイルの更新 更新対象のファイル名をクリックします。 鉛筆アイコンをクリックします。 テキストを修正し、Commit changesボタンを押します。 再度、Commit changesボタンを押します。 ファイルが更新されます。 まとめ GitHubのGUIの使い方の参考になりましたら幸いです。