11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
GitHub Issueのコメントは書く時に戦々恐々とするものです。分量や記載する内容等、コメントというかwikiじゃないかと思えるほどに積もりゆく文章。とりあえず書いた内容がノイズにならないように心がけ始めたことを書いてみました。 GitHub Issueに作業進捗をコメントとしてこまめに書いていた時期がありました。気がつくと短期間で20コメントくらい付いており、内容を読み取るにも各コメントのコンテキスト理解が必要になり、結果大量のノイズと化していました。 フロー型のSNSのノリで書いていたことも原因だったと思います。最近は意識して体裁建てた結果、1コメントに1ページのWikiのようなノリになりつつあります。そんな書くにも悩ましいGitHub Issueのコメントについて、最近構えた個人的な方針を書いてみることにしました。 とりあえずHeaderでタイトルを書く Issueのタイトルをコ
特定ファイルが更新されたタイミングでActionを実施したいものの、ファイル毎にWorkflowが大量に出来上がる状態も防ぎたく、ファイルの状態検知結果が一致したらStepを動かすという手段でやってみました。 GitHub Actionsで特定ファイルの更新に紐付けたStep実施を試してみました。 on:push: にて対象ファイル指定でも問題はないのですが、複数のファイルに対して実施するStepを切り分けたい場合にはファイル毎にWorkflowが増えることも意味しており、判定に用いる条件のみ差分が生じる程度なら一つのファイルに収めたかったためです。 更新履歴からStep実行判定 更新のあったファイル一覧を取得し、その中に求めるファイルが存在するかをチェックします。更新ファイル一覧取得には tj-actions/changed-files を利用しました。 - uses: actions/
初級者の人や、プロジェクトにあとから入ってきた人がわかりやすいようにGitHubのREADME.mdを詳細に書いていくことは大切です。しかし、文字ばかりになるのも味気ないですし、やはり絵や図があったほうがわかりやすいはずです。ふと、画像を貼るにはどうしたらいいのだろうと思ったので調べて実践してみました。 README.mdに画像を貼る手段はいくつかあるようで、外部サービスを利用するものもあります。外部サービスに保存し、そこを参照しに行く方法です。 GitHubでREADME.mdに画像を使用したい - Qiita 個人的にはGitHubの同じリポジトリの中だけで閉じておきたいなと思ったので、空のブランチを用意しその中に画像だけ保存しておく方法を選択しました。今回はそのメモです。 空のブランチを作る方法 空のimagesのブランチを作成します。orphanオプションをつけることによって、元の
githubで複数アカウントを使い分ける方法を紹介します。gitそのものではなくsshの使い方になってしまいますが。 前置き みなさんgithubは使ってますか? 趣味のオープンソース活動だけでなく、最近はお仕事でgithubを利用する人も多くなってきたことでしょう。 そうなると困るのが情報漏えい対策です。githubではお金を払えばprivateなレポジトリや組織を作ることができ、それらを活用することでNDAの下にあるプロジェクトも安心して取り扱えます。というわけで私もプライベートに使ってるアカウントをそのまま仕事に使おうと考え評価していたのですが、ある問題点が浮上しました。githubから飛んでくる通知 メールです。あれをプライベートと仕事で同じメールアカウントに飛ばしてしまうと、オペミスなど万が一の事故が起こらないとは言えないのです。特に粗忽な私はメールのオペミスしやすいですからね。
GitHub provides two ways of connecting to git repositories, namely SSH and HTTPS. HTTPS requires you to supply an access token every time you push to a repository. SSH allows you to push code without remembering your username and token every time you push code to a GitHub repository. So you have a personal GitHub account—everything is working perfectly. But then, you get a new job, and you now nee
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く