GitHubが2019年11月、新機能「GitHub Actions」を正式に公開した。GitHub上のリポジトリやイシューに対するさまざまな操作をトリガーとしてあらかじめ定義しておいた処理を実行できる機能で、今まで外部サービスとの連携が必要だった自動テストや自動ビルドなどがGitHubだけで実現できるようになる。今回はこのGitHub Actionsについて、機能の概要や基本的な使い方などを紹介する。 GitHubだけでCI/CD的な機能を実現できる「GitHub Actions」 昨今では、ソフトウェア開発におけるさまざまな工程を自動化するような技術の開発や普及が進んでいる。その1つに、CI(Continuous Integration、継続的インテグレーション)やCD(Continuous Delivery、継続的デリバリー)と呼ばれるものがある。CIはソフトウェアのビルドやテストを
今週ちまちまと git-messenger.vim や clever-f.vim の CI を GitHub Actions に移行していました.毎回 Vim プラグインの CI のために Vim や Neovim のセットアップを書くのが面倒なのと,Windows 上で Vim や Neovim を入れるのが(Powershell に不慣れなこともあり)大変だったので,GitHub Action として切り出すことにしました. github.com 1ステップで Vim や Neovim を簡単にインストールできます. Vim と Neovim 両対応 Linux, macOS, Windows すべてで動作 'stable' と 'nightly' の両方に対応 追記: 特定バージョンにも対応(v1.1.0) 使い方 下記のようにステップを書けば Vim または Neovim をインス
PCのネットワーク使用状況を確認するツールはWindowsのリソースモニターやLinuxのiftopコマンドなどが有名です。そんなネットワーク監視ツールの一つである「bandwhich」は、CLI上でプロセスごとにネットワークを監視できるコマンドで、ウィンドウサイズに合わせて表示される情報が変化していくツールです。GitHubにソースコードが公開されているので、実際に使ってみました。 GitHub - imsnif/bandwhich: Terminal bandwidth utilization tool (formerly known as "what") https://github.com/imsnif/bandwhich 今回はUbuntuにbandwhichをインストールしてみます。まずはパッケージマネージャーのCargoをインストールするため、下記コマンドを実行します。 cu
GitHub Actions以前調べたのですが、いろいろあって個人プロジェクトでサクッとビルドするのみに使っていました。 今回改めて調べを進めたのでメモ。 幾つかのリポジトリをGitHub Actionsに移行したけど、記事にしようとまとめていたらやった内容以上に調べてめちゃめちゃ時間かかった。 TL;DR トレンド GitHub Actions の基本 使用条件 使用制限 料金 ホストランナーの指定 ハードウェアリソース インストールされるツール IP OSの選択 実行権限 ファイルパス 環境変数 シークレット GITHUB_TOKEN コンテキスト Artifact トリガーイベント Cache Actions 通知 YAML Getting started YAMLシンタックス on env jobs.<job_id>.needs jobs.<job_id>.runs-on jobs
SREチームの長田です。 Advent Calendar Migration Track 22日目の記事です。 今回は弊社で運用しているLobiというサービスの、Webブラウザ版(Web版)をECSに移行したはなしです。 web.lobi.co なぜ移行したのか おなじみ、Amazon Linux1 EoL対応です。 すべてのアプリケーションをEC2から移行するプロジェクトの一環です。 移行前 LobiのWeb版はNuxtJSを使って実装されています *1。 各APIにリクエストし、サーバーサイドレンダリング(SSR)した結果を、Webブラウザに返しています。 NuxtJSアプリは他のアプリケーションも同居するEC2インスタンスで実行していました。 移行前の構成 (実際にはクライアントで動的にコンテンツを更新するためのAPIリクエストも発生しますが、今回の話題には関わってこないので省略して
しばたです。 先日のキーノートで発表され既に弊社社員により多くの記事が書かれているEC2 Image Builderですが、Build ComponentにPowerShell Coreが用意されていることを知ったためPowerShellおじさんとしては重複上等でブログを書かずにはいられませんでした。 (上記の「関連記事」でその他の試してみた記事にもアクセスできます) 前準備 EC2 Image Bbuilder(以後Image Builder)ではEC2インスタンスでパイプラインを実行するにあたり所定のIAMロールを必要とします。 必要なロールはパイプラインの種類によって適宜適切に設定する必要がありますが、単純にPowerShell CoreをインストールするだけであればEC2InstanceProfileForImageBuilderとAmazonSSMManagedInstanceC
動いてるリポジトリはここ https://github.com/mizchi/frontend-gh-action-playground やったこと 発想は https://qiita.com/mizchi/items/9c03df347748ba5f5a11 の続き job 間の依存を明示して build => {各種e2e} というステップでタスクを流す 新たに導入された actions/cache を使って node_modules と dist (webpack 出力ディレクトリ) を cache して次のジョブに渡す node_modules は package.json の ハッシュ値をキーに、 dist は GITHUB_SHA(コミットハッシュ)をキーにした safaridriver が仕様変更で動かなくなったので一旦止めた(サポートにこれ先月動いてたのに今動かないの?って
こんにちは。皆様、夏はいかがお過ごしでしたか。 私は毎年実家に帰省し、そして毎年体調を崩すので、絶対風水的になんか合わないんだと思っています。コネクト支援チームのsakay_yです。 先日、2018年の新人研修資料を公開し、たくさんの反響をいただきました*1。ありがとうございました。 2019年もエンジニア新人研修を行いましたので、その紹介と講義資料を公開いたします。 2019年のエンジニア新人研修について 今年の研修は、組織運営チーム*2が取りまとめ、以下のような3構成となりました。 必修講義 誰に: 開発/運用本部に配属される新入社員 何を: どのチームに行っても必要となる基礎的な知識/技術/ツールを学び、体験できた 選択講義 誰に: 学びたい人が(=新入社員に限らず) 何を: 興味があることを学べた チーム体験(2週間 * 3チーム) 誰に: 開発/運用本部に配属される新入社員
GitHub Marketplace ※v1と同一URL2つあるので、「GitHub Actions」というキーワードでGoogle検索したときに古いv1の情報が出てくることもあるので注意してください。v1前提なのかv2前提なのかで全く内容が異なってきます。 またv1が手元で使えるからといってv2が自動的に使えるわけではありません。それぞれ別物なのでv1が使えてたとしても、v2が利用可能対象ユーザーとして降ってくるまでは使えません。 導入方法設定方法は簡単。GitHub Action v2が使える対象になっていれば、下記のように表示されますので Enable Repository してください。 有効化されると、下記画面が出てくるのでGUIでポチポチワークフローを設定するもよし。 .github/workflows以下に直接YAMLを置くもよし。動くYAMLサンプルは下記の公式 start
GitHub ActionsがCI/CDをビルトインサポート、具体的にはどうなっているか:「GitHubらしいやり方を考えた」(1/2 ページ) GitHubは2019年8月8日(米国時間)、開発者ワークフロー自動化ツールの「GitHub Actions」で、CI/CDのサポートを発表した。具体的にはどのように使えるのだろうか。 GitHubは2019年8月8日(米国時間)、開発者ワークフロー自動化ツールの「GitHub Actions」で、CI/CD(Continuous Integration/Continuous Delivery)のサポートを発表した。正式提供開始は、(同社イベント「GitHub Universe」開催日の)2019年11月13日を予定する。その後も、公開リポジトリではこの機能を無償で利用できることになるという。 2018年10月にGitHub Actionsを発表
マイクロソフトは、Windows 10の次期バージョンで搭載予定のWindows Subsystem for Linux 2(WSL 2)に組み込むLinuxカーネルのソースコードをGitHubで公開しました。 Windows 10には、その内部でLinux互換のAPIを提供する「Windows Subsystem for Linux」(WSL)と呼ばれる機能を搭載しています。 現在Windows 10で提供されている「WSL」は、LinuxシステムコールをWindowsカーネルのシステムコールに変換することでLinux互換環境を実現しています。 しかしこの方法ではLinuxシステムコールとの高度な互換性や高速性を実現することが難しかったため、次期バージョンの「WSL 2」ではLinuxカーネルをまるごとWindows 10内に組み込む仕組みが採用されました。 WSL 2で用いられるLin
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く