ワークフローの概要 このGitHub Actionsワークフローは以下の主要な機能を持っています： 新しいイシューが開かれたときに自動的に起動 イシューの内容を分析し、不適切なコンテンツをチェック 既存のイシューとの重複を検出 必要に応じてラベルを付与 ワークフローの詳細解説 トリガーとパーミッション設定 name: Issue Review on: issues: types: [opened] permissions: issues: write contents: read このセクションでは、ワークフローの名前を定義し、トリガー条件とパーミッションを設定しています。 on.issues.types: [opened]: 新しいイシューが開かれたときにワークフローが起動します。 permissions: ワークフローがイシューの読み書きと、リポジトリコンテンツの読み取りを行うための権

この記事を読むとできるようになること git commitしてpushして、ブラウザ開いてactionsタブを開いてワークフロー探して・・・ というちょっと面倒な手間をなくして、gh-runとターミナルで叩けばワークフローが実行できるようになります。 $ gh-run # my-workflow.ymlをcurrent branchで実行 $ gh-watch # 実行状況をターミナルに表示 $ gh-view # 実行結果をターミナルに表示 $ gh-log # 実行ログをターミナルに表示 # gh # 実行する alias gh-run='gh workflow run .github/workflows/$workflow --ref $(git branch --show-current)' # 実行を見守る alias gh-watch='gh run list --workfl

ブラウザだけでなく、非ブラウザなJavaScript（JS）処理系も増えてきたので、「主要ブラウザ、Node.js、Cloudflare Workersでも動くDenoファーストなTypeScript/JavaScriptモジュール開発＆CI/CD」をやってみました。一事例として共有します。 はじめに 最近、TypeScriptで hpke-js というモジュールをつくりました。 HPKE (Hybrid Public Key Encryption) というのは、ざっくり言うと、公開鍵を交換しあって共有鍵をつくり、安全にEnd-to-End暗号化をおこなうための規格です。これを Web Cryptography API 上に実装し、このAPIをサポートする複数のJS処理系（主要なWebブラウザ、Node.js、Deno、Cloudflare Workers）で動作保証する（ちゃんと全環境で

つくったアプリケーションのソースコードは公開したい、でもシークレットはどうにかして秘匿しないといけない。継続的な運用を目指すならシークレットのデータ自体もなんとかしてリポジトリに（Repository secrets などではなくコミット対象として）含める必要がある。 …という状況を解決するために、gpg だけを使って継続的な運用を図る手段をまとめてみます。フロントエンド/バックエンドなど問わずどこでも使用できます。 Web フロントエンドなどから各種 API キーを利用する場合、リクエスト時の挙動はデベロッパーツールで全て確認できてしまう点には留意してください。 これらは API サーバー側でオリジンの制限をかけるなどの検討が必要です。 やること主な作業内容の要約は gpg を使ってプッシュする前にローカル側で暗号化をする暗号化するときに復号化のための(最強の)パスフレーズを登録するその

GitHub Actions のワークフローを静的にチェックする actionlint というコマンドラインツールを最近つくっていて，概ね欲しい機能が揃って実装も安定してきたので紹介します． github.com なぜワークフローファイルの lint をすべきなのか GitHub Actions が正式リリースされてからだいぶ経ち，GitHub 上での CI は GitHub Actions が第一候補となってきているように感じます．僕も新規にリポジトリを作成して CI をセットアップする場合はほぼ GitHub Actions を使っています． ですが，GitHub Actions には下記のような問題があり，actionlint でそれらを解決・緩和したいというのが理由です． ワークフローを実装する時は，GitHub に push して CI が実行されるのを待って結果を確認するという

tl;dr git rev-parse HEAD^{tree} でツリーオブジェクトのハッシュ値が取れるので、ブランチが異なる場合でも同じソースツリーであるかどうかを判定できます。 これを利用して、すでにテストを通ったtreeのハッシュ値をどこかに記録しておいて、同一のソースツリーに対するテストをスキップできます。 本題 よく使われている、develop/mainブランチ運用をしている場合に、ちょっとした修正を本番に入れたい場合には以下のようなフローを踏むことになるでしょう。 featureブランチをdevelopブランチの先頭から切って修正を作ってテストが通るのを待つ developブランチにfeatureブランチにマージしてテストが通るのを待つ mainブランチにdevelopブランチをマージしてテストが通ったらdeployする さて、この時、他の作業が混ざらない限りにおいては1,2,

こんにちは。Tably よういちろう（@yoichiro）です。 皆さんは普段GitHubをお使いでしょうか？お使いの方は、GitHub Actionsを使ってCI/CDしていますでしょうか？ GitHub Actionsを使うことで、Pull Requestの作成や更新、あるブランチへのマージといったタイミングで、コードのフォーマットを整えたり、テストを走らせたり、本番環境にデプロイしたり、一連の作業が終わったことをチャットに通知したり・・・といったことを自動的に行うことができます。GitHubにはGitHub Marketplaceというアクションが公開されているマーケットプレースがあります。やりたいことがあった時に、一般的なものであればそこで見つけることができるでしょう。 ものすごい数のアクションがMarketplaceにて公開されていますが、たまたま僕が行いたかった動作をしてくれる

TL;DR Go Modules(vgo)はGo1.11から導入され始めたGoの新しいバージョン管理 Go1.12ではまだ有効にはなっていない(Go1.13からはデフォルトで有効になる） Go Modulesの概要とTipsなどを簡単にまとめた Go1.12のModules関連の変更をDockerを動かして確認してみた GOPATHi外でgo.modがなくてもgo run可能 replaceディレクティブで依存パッケージをローカルのコードを使って解決 etc… 確認に利用したDockerfileやスクリプトは以下のリポジトリにある。 https://github.com/budougumi0617/gomodules-explore vgo発表前のGoのバージョン管理は以下のような手法が取られていた。 go getでgo1タグ・ブランチもしくは最新のmasterブランチを取得する go g

この記事はAkatsuki Advent Calendar 2018の12日目の記事です。 前回は hayamaruさんの、知覚メカニズムと網膜投影でした。 はじめに 継続的デリバリーという文脈で、素早く、安全にデプロイする手法について、近年多くの記事を見かけます。 例えば、カナリアのおかげで命拾い : CRE が現場で学んだこと でカナリアリリースについて詳しく触れられています。このアイデアは「たとえテスト環境で十分な検証をしたとしても、本番環境で問題が発生しないということを保証するのは難しいので、少しづつトラフィックを移動して問題があったらすぐにロールバックをしよう」というものです。 上記記事中に紹介されているKayentaといったツールを使ってカナリア分析を行い、自動的にカナリアリリースするというのも良いですが、人間による承認を元にデプロイするならもう少しコストの低い方法で良さそうで

git clone https://github.com/tamanyan/nuxt-ts-netlify.git <project-name> cd <project-name> yarn or npm install GitHubからNetlifyプロジェクト作成 New site from Gitボタンからプロジェクトを作成。 デプロイしたいWebサイトのレポジトリをGitHubから選択 Githubを選択して、自分がデプロイしたいプロジェクトを選択する。 自分で作成したNuxt TypeScriptのプロジェクトを選択する。 Netlify上にWebサイトをビルド 以下の三点を設定する ビルドするブランチ 静的Webサイトをビルドするコマンドを設定。ここではyarn generate ビルド先のディレクトリを指定。ここではdist 追加のビルド設定だと、環境変数なども組み込めるよう

qiita.com 個人開発アドベントカレンダー9日目です! (2週間遅れです... 🙏) 一年前に開発してた Web サービスで、このような構成の開発をしていました。 個人開発はとにかく時間が足りないので、既存のサービスを使える場合はそのサービスを使って開発を行いました。 開発していたものは結局リリースしなかったのですが、CI や SaaS を使い快適に開発できたので、使っていたサービスや構成について書いていきます。 これは個人開発での遊びであり、これで商用サービスもいけるかというとわかりません。 (それと私は iOS エンジニアであり、サーバサイドは門外漢です) サービス概要 Lastfm のような、音楽を再生したらその履歴をとって何回再生したか、いつどこで再生したかなどを自分が聞いた音楽を歴史として遡れるようなアプリを作っていた。 メインの技術スタックは Rails + Herok

はじめに Golangをちまちまプライベートで触っていて、バックエンドサーバを試しにgolangで書いてみてるんだけど、Jenkinsのpipelineでgoを扱う方法が、調査しても断片的にしか出てこなかったので、本腰を入れて調査してみた。 pipelineでなければ、もっと簡単そうだけど、BlueOceanも1.0リリースされたしね。 みんなのGo言語【現場で使える実践テクニック】 作者: 松木雅幸,mattn,藤原俊一郎,中島大一,牧大輔,鈴木健太,稲葉貴洋出版社/メーカー: 技術評論社発売日: 2016/09/09メディア: 大型本この商品を含むブログ (3件) を見る 対象 ソースコードはこちら github.com 単なる足し算を実装しただけの簡易なもの。 しかも明らかにミスってる(もちろんわざと) func Sum(a int, b int) int { return a +

Gotanda.unity #13 in CyberAgent@渋谷 https://gotanda-unity.connpass.com/event/134867/ 登壇者：御厨

gitlab.comは自前でDocker image登録できたり、CI持っていたりと便利ですね。しかも、privateレポジトリもお金かからないという太っ腹。 技術書典2に向けたレポジトリはgitlab.comで管理しています。 今回は共著者にPython使いが多いためSphinxを使って書いているんですが、Sphinxはcommon markでも書けるのでmarkdownでも文章を書くことが出来ます。 前回の記事では、数式入りのmarkdownからPDFを生成するDocker imageを作りましたが、それを使うと簡単にGitlab-CIでPDFが生成できます。 chezou.hatenablog.com やり方は簡単、あなたのSphinxのプロジェクトに、以下のような.gitlab-ci.ymlを書くだけ。もちろん、必要に応じてpathsは変更してください。 image: chezou

最近，環境ごとのデータベーススキーマの差分をチェックする機会があった．プロダクション環境とステージング環境ならまだしも，開発環境だと検証のために追加したインデックスがそのままになっていたり，開発が途中で止まってしまって日の目を見ることがなかったテーブルが残っていたり，そういうことって比較的あるのではないかなと思う．特に今の環境だと，マイグレーションの仕組みが整っていないという課題もあり，より一層，データベーススキーマに差分が出やすくなってしまっている． 今回は MySQL から公式に提供されている mysqldiff というツールを使ってデータベーススキーマの差分をチェックした． mysqldiff をインストールする mysqldiff は MySQL Utilities という MySQL の管理ツールパッケージの中に同梱されている．現在だと v1.6 が最新になっている． MySQL

⠀人 / ⁰⊖⁰ \ オカメインコエンジニアの五十嵐(@ganta0087)です。 CrowdWorksでは、サービスのCI環境としてCirlceCIを利用しています。 今回、CircleCI 1.0から2.0に移行すると同時に、新機能のキャッシュをフル活用したことで、コストを増加させることなくCI実行時間を半分にすることができました。 今回の記事では、CirlceCI 2.0のメリットや、どのようなチューニングを行ったのかをご紹介します。 CircleCI 2.0について CircleCI 2.0は現在ベータ版となっており、「CircleCI 2.0: Beta Access - CircleCI」から申し込むことができます。(試してみたところ個人のリポジトリではすぐに利用できるようです。) 申請したOrganizationのすべてのプロジェクトで突然バージョンが切り替わるわけではなく、

こんにちはー！こねひとちほーのえんじにあのフレンズ@Utmrerだよー！ 今回はPull Requestを自動でチェックしてくれるDangerについて紹介します。 Pull Requestでのコミュニケーション Pull Requestのレビューは不具合の指摘やコーディングスタイルの統一、より良いコードのための提案などのために行われます。 ですが、次のようなコミュニケーションをしたことはありませんか…？ タイトルにIssue Idを含めてもらえますか？ WIPみたいなんですがレビューして大丈夫ですか？ Base branchが間違ってます、変更してください。 変更履歴のdocsを更新してください。 このような「実装とは関係のない指摘」はできるだけ減らし、自動化したいものです。それを実現するのがDangerです。 Dangerとは DangerのGitHubには次のように書かれています。 F

皆さんこんにちは. 現在はfluctにてfluct DRという広告配信システムの開発を行っております, 大関です. GitHub上でのチーム開発では, レビューの依頼や, CIが通ったことを確認した上でのPull Requestのマージといった複数の作業が発生しますが, これらはGitHubのUIを複数回クリックする必要があり, 非常にストレスフルな作業です. 本稿では, こうした定形作業を自動化するbotとしてpopukoを開発・導入することで, 我々開発者のストレスを軽減するとともに, より堅牢かつフィードバックの多い開発が実施できるようになった事例を紹介します. GitHubでの開発はとてもクリック操作が多い 前段でも述べたように, GitHubを用いたチーム開発においては, 数多くの定形作業が存在します. コードレビューの可能な人を探してレビューを依頼する, 依頼の度に対象者をAs

こんにちは、id:Pocke です。 この記事では、Go Meta Linter がサポートするツールについて記そうと思います。 Go Meta Linter とは Go Meta Linter とは、Go言語で使用できるLinterをまとめて実行することが出来るツールです。 そのため、Go Meta Linterは多くのGoのツールに依存しています。 この記事では、その依存している各ツールがどのような機能を持つのかを述べようと思います。 なお、既に Go の CI で lint と カバレッジ回して非人間的なレビューは自動化しよう in 2016年 - haya14busa という素晴らしい記事があるため、そちらで説明されているツールに関しては適宜この記事へのリンクを貼っています。 上記の記事で言及されていないツールを重点的に説明させていただきます。 Check 三兄弟 レポジトリ: o