GitHub Actions Workflow チェックリスト | CyberAgent Developers Blog
GitHub Actions Workflow Best Practices こんにちは。2022年新卒入社の上田です。現在は本配属前のジョブロで ABEMA に所属しております。 この記事では GitHub Actions workflow/job 作成に関するベストプラクティスをまとめました。 workflow/job 追加時に参照できるチェックリストとしてご利用いただけるような一記事として公開しています。堅牢で安全な CI/CD pipeline を作る参考になれば幸いです。 （ジョブロ：メディア事業部における新卒研修の一環として二ヶ月間実施される本配属前のジョブローテーション研修） 自己紹介 GitHub Actions は Beta v1 の頃から利用しており、個人としても peaceiris/actions-gh-pages などをはじめとして、いくつかのサードパーティー Ac
GitHub ActionsにおけるStep/Job/Workflow設計論
この記事について GitHub Actionsには、以下3つの実行単位が存在します。 Workflow Job Step パイプラインを組む中で出てくる複数個の処理を、1つの実行単位でまとめてしまうか、それとも分割するのかというのは悩むポイントかと思います。 一つのstepのrunフィールドにコマンドを詰め込む？それともstepを分けた方がいい？ 一つのJobの中のstepとして記述した方がいい？それとも別のJobに定義した方がいい？ 一つのWorkflowの中にJobをたくさん定義する？それともWorkflowを別にする？ この記事では、Workflow・Job・Stepそれぞれの性質を踏まえた上で、ベストな処理単位の選び方を考察します。 使用する環境・バージョン GitHub Actions: 2022/5/15時点での機能をもとに考察 読者に要求する前提知識 GitHub Actio
Pull RequestのコメントからGitHub Actionsを実行する - あかいものログ
GitHubのPull Requestのコメントから任意のGitHub Actionsを実行する必要があり、やり方に少々癖があったので紹介します。 issue_comment ドキュメントを眺めているとPull Requestに関連するイベントはいくつかありますが、Pull Requestのコメントをトリガーとしたイベントが無いように見えます。 pull_requestイベントはPull Requestの作成やラベル付けをトリガーとするイベント pull_request_reviewイベントはレビューされたときをトリガーとするイベント pull_request_review_commentイベントはレビューについたコメントに関するイベント どうにかPull Requestのコメントをトリガーに起動できないか調べていたらCommunity Forumで以下の投稿を見つけました。 github
GitHub のラベルを宣言的に管理する - tellme.tokyo
ソフトウェアの宣言的設定について “何かを管理する"となったときに、宣言的に設定できるようになっていると非常に便利である。 この宣言的設定 (Infrastructure as Code) とは、イミュータブルなインフラ (Immutable Infrastructure) を作るための基本的な考え方で、システムの状態を設定ファイルにて宣言するという考え方である。 具体的には Kubernetes のマニフェストファイル (YAML) だったり、Terraform のコード (HCL) が挙げられる。 この考え方は、インフラ領域に限らず、何らかの状態管理にはもってこいの手法である。 GitHub のラベルは Issues/P-Rs を管理するために便利な機能である。 しかし、リポジトリの規模やラベルの数が増えてくると、ラベル自体も管理する必要が出てくる。 実際に Kubernetes 規模
プロダクトのドキュメントにプルリクエストを送れる仕組みがすごい - Qiita
これ↓なんですけど、意外と RT や Like が付いてたので、ちゃんと書きますね。 しっかしMicrosoftのドキュメントシステム良く出来てるなー。右のEditボタン押すとGitHubが開いてすぐPR送れる。あちらでマージされれば即サイトに反映される。Contiributorsに自分のアイコンが増えた♪ これはフィードバックするのに「面倒」は理由にできないですぞ。https://t.co/9KhAwhV5PP pic.twitter.com/r46zFUvkEp — あめいぱわーにおまかせろ! (@amay077) 2018年6月12日 このツイは Microsoft の製品やサービスのドキュメントについてなんですが、 Microsoft Docs というポータルがありまして、同社のサービスの多くはここでドキュメント公開されている模様です。 ここで公開されているドキュメント群は、バック
Githubがデザインシステムを作るまでの道のり（前編）
Jerry Cao氏は、UXPinのコンテンツストラテジスト。プラットフォームのワイヤーフレーミングとプロトタイピングを行うためのアプリ内およびオンラインのコンテンツを開発しています。 Diana Mounter氏はGithubのプロダクトデザイナーおよびデザインシステムのリーダーです。 デザインと開発において15年近いキャリアをもつ彼女は、Etsyでシニアデザイナーを務めた後、2015年末にGithubのチームに参加しました。 私たちはこのインタビューで彼女に、デザインシステムにおけるベストプラクティスと、デザインシステムの作成・保守の経験から学んだ教訓について聞きました。このインタビューは、動画で見ることもできます。 また、デザインシステムの利点やプロセスについてもっと知りたければ、無料のeブック『Why Build a Design System？』をダウンロードしてください。 Gi
プログラムのネーミングに迷ったら GitHub でコード検索すると参考になる説 - Qiita
TL;DR プログラムのネーミングで迷ったら GitHub でキーワードを検索して、ヒットした件数が参考になるのでは？ 複数キーワードを検索して結果の一覧を表示する CLI 作りました https://github.com/kyoshidajp/ghkw ネーミング迷いますよね？ みなさん、コードを書いていて変数やメソッド名のネーミングって迷いますね。 こんな時に自分たちはチームを横断して「こういう名前考えたんだけど、これってどうかな？」という確認を Slack 上で行っています。先日、この Slack チャンネルを見ていて考えました。 「**GitHub で検索すれば世の中のコードでどのぐらい使われているかざっくり分かるので参考になるのでは？**説」 GitHub で検索できるという条件付きではありますが、コードの規模からするとある程度期待できそうです。 GitHub で検索 例えば「除
`ghg` で GitHub Releasesから適切な実行ファイルを統一的に取得する | おそらくはそれさえも平凡な日々
https://github.com/Songmu/ghg tl;dr % ghg get motemen/ghq とかやれば、GitHub Releasesに上がった最新の実行ファイルを取得できる。 % $(ghg bin)/ghq とかで実行可能。 $(ghg bin) を $PATH に追加してもよい。 % ghg get Songmu/ghch@v0.0.1 とかでバージョン指定も可能。 本文 Goで書いたツールを提供する場合、クロスビルドしたものを GitHub Releasesに上げるのが定番となっています。 なぜ、 go get ではないのかというと go get の場合以下のような問題があるからです。 go get するにはGoの環境が必要 安定版ではなく、開発中の最新をビルドしてしまう ビルド情報などをバイナリに埋め込めない ただし、GitHub Releasesに上げる
GitHubのIssueやPull requestで頻出する英語の略語達 - Qiita
GitHubのIssueやPull Requestで頻出する省略語とその意味まとめ 省略語 非省略形 意味 LGTM Looks good to me 良いと思う。(よさげ) nit nitpicks 細かい指摘 IMO In my opinion 私なら、私の考えなら IMHO In my humble opinion つまらない意見ですが WDYT what do you think? どう思う？ :shipit: ship it マージ / デプロイしよう。 BTW by the way ところで e.g. for example たとえば i.e. id est(ラテン語) すなわち、言い換えれば FYI For your infomation あなたのための情報 cf compare 比較、参照 EOM End Of Message メッセージ終わり。件名のみで要件を伝える場合等
GitHub releasesのフィードを購読する - その手の平は尻もつかめるさ
生きているとOSSのライブラリを使ったり，OSSのソフトウェアを使用することになるでしょう． そうなってくると内部実装や変更点を逐一知りたくなるというのが人情というものです． GitHubでコードが公開されているのであれば，「リポジトリをwatchする」というのは有効な方法に思えますが，しかしwatchしているリポジトリが増えてくると現状のGitHubのタイムラインは即座に崩壊し，容易に取りこぼしが生じてしまうでしょう．これはGitHubのタイムラインの問題の一つだと思っていて，なんとかなって欲しい点はあります (例えばタイムラインを分割できるとか……)． というわけでどうするか．もちろんAtomフィードです． https://github.com/{author}/{repos}/releases.atom と指定してやると当該repositoryのGitHub releasesをAto
git blameでプルリクエストの番号を表示する
GitHubでプルリクエスト前提の開発をしていると、git blameで「なぜ、このコードがこうなっているのか」調べる際に、commit idではなくプルリクエストの番号を表示してほしくなります。 というわけで書いたのが git-blame-pr.pl。 以下のような感じで表示されるので、調査がはかどります。 $ git-blame-pr.pl lib/core/request.c (中略) PR #446 PR #606 h2o_iovec_t h2o_get_redirect_method(h2o_iovec_t method, int status) PR #606 { PR #606 if (h2o_memis(method.base, method.len, H2O_STRLIT("POST")) && !(status == 307 || status == 308)) PR
Shields.io | Shields.io
Dynamic badges Show metrics for your project. We've got badges for hundreds of services.
GithubでTILというリポジトリが流行りつつあるのかもしれない - 生涯未熟
Githubで海外のエンジニアさんをフォローしているのですが、あるエンジニアさんがtilというリポジトリをstarしていました。 github.com 「なんか新しいツールか何かかな？」と思ったのですが、覗いてみたらdescriptionに"Today I learned"の文字が。 どうもtilというリポジトリを作成してそこに"今日覚えたこと"を書いていくのがプチ流行している様子。 ・ 色んなTILが 今までだと同じような感じでベストプラクティス等をまとめた"◯◯-awesome"が流行ってましたが、 自分が何を学んでいっているのか自分も他人にも知ってもらうためにこういうリポジトリを作って書いていくのも面白そうですね。 関連したWebサービスとかが作成されたらそれはそれでまた面白いのかも。
GitHub の新しい Organization パーミッションモデル（2015年10月リリース）について理解する | まくまく Git ノート
GitHub の Organization アカウントの新しいパーミッションモデルが公開されました。 https://github.com/blog/2064-new-organization-permissions-now-available チームメンテナの設定が可能 チーム内のメンバに対して、team maintainer という役割を設定できるようになりました（念願！）。 これまでは、各チームに対するメンバ追加を行うときは、Organization の Owners メンバが追加作業を行う必要がありましたが、この機能によって、チーム内のメンバ管理は、そのチームの代表者に任せることができるようになります。 設定方法 Organization のトップページから Teams を選択 対象のチームを選択 チームメンテナに設定したいメンバの設定アイコンをクリックし、Promote to t
GitHubのPull Requestを簡単にチェックアウトするたった1つの方法 - アジャイルSEの憂鬱
みんな知ってるものだと思ったけど、あまり周りで知ってる人がいなかったのでブログに書いた。 こういう釣りタイトルっぽいブログ、一度書いてみたかった。 参考 Checking out pull requests locally - User Documentation 参考というか、そのままだけど。 方法 Pull Requestの ID を BRANCHNAME にfetchします。 *1 $ git fetch origin pull/ID/head:BRANCHNAME ブランチをcheckoutします。 git checkout BRANCHNAME これだけです。forkした人のリポジトリを remote add する必要はないです。 おまけ マージ後のsha1 ちなみに、Pull Requestのマージ前だと、 pull/ID/merge を使うこともできます。 $ git fet
高速に自作パッケージをGithubにリリースするghrというツールをつくった
高速に自作パッケージをGithubにリリースするghrというツールをつくった tcnksm/ghr・Github ghrを使えば，1コマンドでGithubにリリースページの作成とそこへのパッケージのアップロードが可能になる．複数パッケージのアップロードは並列で実行される． デモ 以下は簡単な動作例． 上のデモでは，v0.1.0タグでリリースを作成し，pkg/dist/v0.1.0以下の6つのファイルを並列でアップロードしている（ghrをghrでリリースしている）．1ファイルあたり，2.0M程度なのでまあま速いかと．アップロード結果は，ここで見られる． 背景 “Go言語のツールをクロスコンパイルしてGithubにリリースする” 上で書いたようにcurl使って頑張ってAPIを叩いていたが，やっぱシェルスクリプトは嫌だし，アップロードが遅い． Githubへのリリースを行う専用ツールでaktau
怖くない！エンジニア以外のメンバに気持ちよく GitHub を使い始めてもらうには - クックパッド開発者ブログ
ヘルスケア事業部の濱田です。チームで楽しく開発してますか？ コードベースの置き場として絶大な支持を集める GitHub。コードを管理するだけでなく、issue を使って様々な議論や報告を行い、その結果をスムーズに製品に反映させることができます。エンジニアだけでなく他の職種のメンバも巻き込んで GitHub で議論ができたら、開発はもっと活発になるでしょう。 一方、 GitHub にはちょっと敷居が高い、敬遠したくなるような雰囲気を感じる人も多いようです。 本記事では、様々な職種のメンバが GitHub を気持ちよく使い始めてもらうにはどうすればよいか、という観点から気をつけるべきことを紹介します。 GitHub は非エンジニアにとっては怖い場所？ エンジニアは GitHub が大好きです。自分たちの作ったコードがあり、ドキュメントがあり、仲間がおり、コードレビューを通じて自分の新たに作った
githubの特定ブランチへのgit push --forceをprotectしてエンジニアの精神崩壊を防ぐ( ꒪﹃ ꒪)ﾌﾞｸﾌﾞｸ - Qiita
Protected branches and required status checks もうお済みですか！？ 9月4日のことですがgithubより以下の機能がリリースされています。 特定ブランチへのforce pushを無効する 特定ブランチへのマージ時にステータスチェックを必須にする(CIと連携している場合は、テストが通るまでマージできないようにできる) これを実施することで、ある日新人が謎の空のコミットをmasterブランチにforce pushして来たり、ある日途中からJOINした人がpull reqもせずにdevelopブランチに謎コミットをforce pushして来たり、ある日とあるOSSで間違えて一ヶ月前のローカルレポジトリをgit push --forceしてしまうなんてこともなくなるんです！！！(githubを使っていれば) あなたの隣のエンジニアが、いきなり発狂して口
オレ流 Pull Request 作業フロー - 詩と創作・思索のひろば
チームで作業する同じリポジトリの中で Pull Request を送り合うのではなく、オープンソースプロジェクトに外部から PR がやってくる場合の話です。 最近のフロー 送られてきた PR に対しては、大まかには仕様の話、実装方針の話、具体的な実装の話を詰めながらマージできるように持っていくわけだけれど、それがほとんど満足いく状態になっていてマージしたいと思うタイミングになっても、変数の名前付けだとか、ちょっとした処理の書き方だとかで、相手にお願いするよりは自分で手を加えてからマージした方が手っ取り早いことがある。そういう時は PR 元のブランチを手元にチェックアウトして、そのブランチを自分の変更で進めた上で master にマージするようにすると、push 時に PR も閉じられて便利です。 motemen/lgtm.sh#1 の例。分かりにくいれど、PR にさらに 1 コミット足して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHubを快適にブラウジングするための3種の神器
