You can configure your workflows to run when specific activity on GitHub happens, at a scheduled time, or when an event outside of GitHub occurs.
error-pages GET / ✓ should respond with page list Accept: text/html GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500 ✓ should respond with 500 Accept: application/json GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500 ✓ should respond with 500 Accept: text/plain GET /403 ✓ should respond with 403 GET /404 ✓ should respond with 404 GET /500
Docker Hub から GitHub Packages へ Git tag やブランチをトリガーに Docker image を自動でビルドして Docker registry で公開・配布したいとなると、まず Docker Hub の利用が候補として考えられます。 あれだけの機能を無料で提供してくれている Docker Hub 開発チームには本当に感謝しているのですが、一点だけ不満があります。実行時間です。Docker Hub はビルドの開始が遅く、実行時間も結構かかりがちです。 これの解決策として外部サービスで Docker image をビルドして、そこから Registry に image を Push することが考えられます。外部サービスには色々な選択肢がありますが、今回は GitHub Actions を選びました。ビルド行程を GitHub Actions で行えば Do
EnterpriseProductGitHub Enterprise Server 2.22 is hereGitHub Enterprise Server 2.22 is now here with GitHub Actions, Packages and Advanced Security Code Scanning available for the very first time. Today, we’re releasing our biggest ever update to GitHub Enterprise Server! In this release, we’ve brought GitHub Actions and Packages to Enterprise Server for the very first time. That means you can now
この記事はCyberAgent Developers Advent Calendar 2021 10日目の記事です。 昨日はみーとみさんの「待機児童問題にマーケットデザインで挑む」でした。 はじめに CIU (CyberAgent group Infrastructure Unit) の中西 (@whywaita) です。 普段はプライベートクラウドであるCycloudのIaaSから上のレイヤーを中心に開発運用を担当しています。 直近ではGitHubからリリースされているGitHub ActionsというCIサービスに関連したmyshoesというソフトウェアを開発しています。 myshoesはOSSで公開されており、直近でもいくつかmyshoesについて登壇させていただいたので興味のある方はぜひこちらをご覧ください。 CyberAgent における OSS の CI/CD 基盤開発 mys
概要 GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。 リポジトリに対するすべての pull request をビルドしてテストしたり、マージされた pull request を運用環境にデプロイしたりするワークフローを作成できます。 GitHub Actions は、DevOps であるだけでなく、リポジトリで他のイベントが発生したときにワークフローを実行できます。 たとえば、リポジトリで新しい issue が作成されるたびに、適切なラベルを自動的に追加するワークフローを実行できます。 GitHub では、ワークフローを実行するための Linux、Windows、macOS 仮想マシンが提供されます。また、自身のデータセンターまたはクラウド インフラストラクチャで独自
はじめに GitHub ActionsでDockerのコンテナをBuildするとデフォルトだとLayerのCache?がされないため、毎回Dockerfileの先頭から実行することになります(何も工夫をしないと)。 「LocalでBuildするときは(Cacheが効いて)速いんだけど、GitHub Actionsだと遅い」というのは、Buildに時間がかかる場合結構しんどいです(Twitterなどが捗ってしまう)。 色々方法があるようですが、Dockerのマルチステージビルドを使っていないなら、割と簡単にCacheを効かせられるようなので、そのメモです(主に自分用)。 ポイントは docker buildコマンドの --cache-from と --build-arg BUILDKIT_INLINE_CACHE=1 になります。また、このOptionを指定するには、BuildKitを有効に
## はじめにCloud Run を利用するとコンテナイメージさえ用意すればシュッとデプロイして公開できます。 僕は Slack の Bot などで簡単な HTTP サーバーが欲しいときに Cloud Run を使っています。 GitHub Actions を利用して Cloud Run への継続的デリバリーを行う GitHub テンプレートを公開しました。 テンプレートなので新しいプライベートレポジトリに利用することも出来ます。気軽に使ってみてください。 sachaos/cloud-run-with-github-actions ## 機能GitHub ActionsDocker イメージのビルドGCR ( Google Container Registry ) へのイメージのアップロードCloud Run へのデプロイGitHub Deployments API を利用した Deplo
GitHub Actions: Environments, environment protection rules and environment secrets (beta) actions December 15, 2020 Today we are releasing an open beta for the new continuous delivery capabilities in GitHub Actions. In this open beta there is no need to sign up, all existing GitHub organizations and accounts can use the new capabilities in their public repositories and GitHub Enterprise Cloud orga
Hacking Bluetooth to Brew Coffee from GitHub Actions: Part 1 - Bluetooth Investigation permalink This is going to be a long journey in three parts that covers the odyssey of getting a new coffeemaker, learning BTLE and how it works, reverse-engineering the Bluetooth interface and Android applications for the coffeemaker, writing a Rust-based CLI interface, and finally, hooking it all up to a GitHu
コンテナのビルドからECS Task Definitionの更新は一貫して行いたい作業であり, CIツールは課題に対する解を提供します. そしてECSへのデプロイまでに行うべきことはほとんどの場合で同一であります. なのでCIツールの中で再利用可能な手法が取れればパイプラインの構築を高速にかつ容易にしアプリケーション開発に注力することが出来ます. GitHub ActionsではAWSが提供しているActionsがありこれを利用することで少ない設定でECSへのデプロイまで実行することが出来ます. 今回はECS Task Definitionの更新までを実際に試してみます. AWS for GitHub Actions 「AWS for GitHub Actions」はAWSリソースへ対する操作をGitHub Actions上から実行する便利なActionsです. AWSが提供しておりアクセ
mkr とは何ですか? Mackerel の CLI です. GitHub Actions 上で mkr をセットアップする setup-mkr アクションを作りました. github.com こういう感じで uses: susisu/setup-mkr@v1 と一行書くだけで mkr コマンドが使えるようになります. steps: - uses: susisu/setup-mkr@v1 - run: mkr org env: MACKEREL_APIKEY: ${{ secrets.MACKEREL_APIKEY }} mkr の詳しい使い方はここでは紹介しませんが, mkr throw で何らかのメトリックを投稿したり, mkr wrap でジョブの成否を監視したり, mkr annotations create でイベントを記録したりといったことに利用できるかなと思います. さてここ
はじめに Dockerイメージのビルドは構成次第で長い時間が掛かり、GitHub Actions上で行う場合に頻度が高くなると利用可能枠の圧迫につながります。Organization全体の限度枠をどのくらい占めているのか、及び残り利用枠が分かりにくいこともあり、先んじてキャッシュして備えることにしました。 効率のよいキャッシュを検討する キャッシュを目的としたActionはいくつかありましたが、今回は使いません。BuildKitプロジェクト成果物のソースコード内での利用形跡が見つからなかったためです。 BuildKitについて 以下のスライドが参考になります。Dockerfile内で効率よくキャッシュするコツにも触れているので、読まれたことがない方には特におすすめします。 BuildKitを併用してキャッシュした場合の時間については、以下のブログ記事にまとまっています。 やってみる 同様の
コンテキストについて コンテキストは、ワークフローの実行、変数、ランナーの環境、ジョブ、ステップに関する情報にアクセスする方法です。 各コンテキストは、プロパティを含むオブジェクトであり、文字列またはその他のオブジェクトにすることができます。 コンテキスト、オブジェクト、プロパティは、ワークフローの実行条件によって大きく異なります。 たとえば、matrix コンテキストはマトリックス内のジョブに対してのみ設定されます。 式構文を使用してコンテキストにアクセスできます。 詳しくは、「式」を参照してください。 ${{ <context> }} 警告: ワークフローとアクションを作成するときは、コードが攻撃者からの信頼されていない入力を実行する可能性があるかどうかを常に考慮する必要があります。 攻撃者が悪意あるコンテンツを挿入してくるかもしれないので、特定のコンテキストは信頼できない入力として扱
FirebaseとGitHub Actionsがマイブームの id:kouki_dan です。 つい先日Firebase App Distributionがリリースされましたね! firebase.google.com FirebaseはFabricの機能を順次Firebaseで扱えるようにしていますが、App Distributionは今までFabric Betaで行なっていたBeta版、テスト版のアプリを社内やテスターの方に配布できるサービスです。 似たようなサービスとしてはDeployGateが有名ですね。 そんなFirebase App DistributionをGitHub Actionsで使ってみようというのが今回の記事になっています。GitHub Actionsのおかげで、外部CIを使うことなくビルドの自動化が行えるようになりました。 iOSアプリのDistribution
github.blog という記事を今日みて、 echo "::set-output name=hoge::fuga" みたいなことをやってたのがdeprecatedになると知った。以下のドキュメントを参考に置換すればOKとのことだったので、せっかくなのでsedでやってみた。 https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter find .github/workflows -type f | xargs sed -i '' -e 's/echo "::set-output name=\(.*\)::\(.*\)"/echo "\1=\2" >> $GITHUB_OUTPUT/g' ちなみにはじめは sed -i
タイトルが長い。 fork されたリポジトリからの pull request を受け取ったとき、GitHub Actions が fork 元のリポジトリの secrets にアクセスするためには例えば pull_request_target という trigger を使うやり方がある。pull_request_target という trigger は便利なんだけど、これを無配慮に使うとセキュリティ的に危ういということが GitHub のドキュメントにはつらつら書かれており、まあつまりどういうことなんや、どう使えばええということなんや、ということで色々調べたのでメモしておく。 まず先に pull_request という triggergithub actions の trigger にはいろいろなものを設定できるが、基本的には pull_request という trigger を使えば p
前提知識 GitHub Actionsは「ソフトウェアワークフローを簡単に自動化するサービス」。 有名どころだとCircleCI的なやつ。CI/CDとかの開発時に必要となる作業を自動化できるサービス。 基本的には.ymlファイルに色々設定とコマンド書けば使えるすごいやつだよ。 長すぎて読めない人 GitHub Actionsを使って独自のアクションをつくった PRとかIssueでコメントにLGTMってあったら現場猫が「ヨシ!」ってしてくれる 初めて作ったので、Tipsもまとめておく つくったアクションの概要 リポジトリは以下(スターおねがいします) 設定するとGitHub上でPRやIssue上でLGTMとコメントすると「ヨシ!」って画像が貼られる 😺.。oO(この人がLGTMって言ってたらたぶん大丈夫や...! ヨシ!w) 使い方 任意のリポジトリに以下のファイルを.github/wor
みなさんこんにちは。 GitHub Actionsを使ってnpmに自動リリースできたら便利だと思いました。やりました。 想定しているフロー 雑で申し訳ないですが下のようなフローを想定しています。 各々がtopicブランチで開発を行う topicブランチで開発が終わったものをversionブランチにmergeしていく mergeが全て終わったら、package.jsonのバージョンをあげる topicブランチをmasterブランチにmergeする masterへのmerge契機でGitHub Actionsを実行してリモートリポジトリへのタグ付けとnpmへのリリースを行う master ---------------------------------> | リリースする version------+--------------------------> | featureブランチにvers
June 30, 2023 Dependabot version updates helps you keep your dependencies up-to-date by opening pull requests when dependencies can be upgraded. With today's release, you can now group version updates by dependency name. Until today, Dependabot would always open individual pull requests for every dependency update in accordance with your configuration in dependabot.yml. Not only can this result in
スタサプ小中高を開発している Android エンジニアの@maxfie1d、@morayl とスタサプ ENGLISHを開発している Android エンジニアの田村です。 GitHub Actions(以下 GHA) はアプリをビルドしたりストアに配信したりすることに使えるのはもちろん、もっともっと色々なタスクを自動化することができます。本記事では Androidチームによる GHA を使った自動化レシピをご紹介します。 まずはスタサプ小中 Android版での取り組みを紹介します。 自動でラベルを付与する 2023年9月に リニューアルをしたスタディサプリ 小学講座をリリースしました。アプリとしてはスタディサプリ 中学講座 と同じで 1アプリ内に中学生向けの機能と小学生向けの機能があります。 コードは中学生向けの機能と小学生向けの機能で大きく original/ elementary
Overview Rather than copying and pasting from one workflow to another, you can make workflows reusable. You and anyone with access to the reusable workflow can then call the reusable workflow from another workflow. Reusing workflows avoids duplication. This makes workflows easier to maintain and allows you to create new workflows more quickly by building on the work of others, just as you do with
このエントリは Mackerel Advent Calendar 2022 および GitHub Actions Advent Calendar 2022 の20日目の記事です。*1 今回はMackerelのサービスメトリックを投稿するためのGitHub Actionsを新規で作ったのでその紹介をします。 GitHub Actions経由でメトリクスを簡単にMackerelに投稿したい 既存のGitHub Actions yutailang0119/action-mackerel-api susisu/setup-mkr 自分のユースケースでの気になり stefafafan/post-mackerel-metrics の紹介 実際に活用している事例 テクニック紹介: 他のStepからMultiline Stringの受け渡し 初めて作ったGitHub Actionについての感想や困りなど
自宅から発送出品者自身が梱包・配送します。「発送までの日数」は、BOOTHでの入金確認が完了してから商品が発送されるまでの予定日数です。 あんしんBOOTHパック で発送予定の商品は、匿名で配送されます。 【概要】 本書は、『GitHub Actions』の入門書です。 GitHub が提供する CI/CD サービスの GitHub Actions の基礎的な知識からはじめ、実際に活用してみるところまで扱います。 A5 相当で 150 ページあります。 【想定読者】 GitHub Actions の入門者から中級者を対象としています。 この本は、以下の三点を意識しながら書かれています。 ・GitHub Actions について体系的に学べる ・実際に手を動かしながら学べる ・普段 GitHub Actions を利用する上でリファレンスとして使える 【目次】 詳細な目次は、商品画像でご確認
Git scraping: track changes over time by scraping to a Git repository 9th October 2020 Git scraping is the name I’ve given a scraping technique that I’ve been experimenting with for a few years now. It’s really effective, and more people should use it. Update 5th March 2021: I presented a version of this post as a five minute lightning talk at NICAR 2021, which includes a live coding demo of build
GitHub Actions: Workflows triggered by Dependabot PRs will run with read-only permissions actionssecurity February 19, 2021 Starting March 1st, 2021 workflow runs that are triggered by Dependabot from push, pull_request, pull_request_review, or pull_request_review_comment events will be treated as if they were opened from a repository fork. This means they will receive a read-only GITHUB_TOKEN and
前置き GitHub Actionsが刷新されてHCLからYAMLでCIを作成できるようになりました。 前まではAction毎にDockerfileを必ず用意する必要がありましたが、Ubuntu・Windows・MacOS上でCIを回すことが可能となり、Dockerfileのメンテナンスが要らなくなりました。<- まじ感謝 では、新しくなったGitHub Actionsを使用してどのようにCIを作ったか説明していきたいと思います。 概要 今回作成してみたCIは、Pythonで開発したアプリケーションをDockerizeしてAWS ECRへプッシュするというものです。 Pushする前にソースコードのLintチェック、テストの実行、Trivyを使用した脆弱性診断、Dockleを用いたセキュリテイ診断を並列に実施します。並列に実行できるJobは20個までとなっているので、今回の規模であれば余裕で
TL;DR: For any developer looking to avoid security vulnerabilities, buttons that don’t work, slow site speeds, or manually writing release notes this is for you. As developers, we get a bad rap for not writing tests—or automations for that matter—as much as we should. It’s not that we don’t do it (well, maybe some of us don’t). But it’s a fact that writing more code can be a little more fun than s
趣味で mod_perl の Docker イメージを作っています。 Docker Hub の無料版における autobuild が終了となり、GitHub Packages Container Registry に移行することにした。 https://github.com/motemen/docker-mod_perl/pkgs/container/mod_perl {perl_version}-{httpd_version}-{mod_perl_version} て感じのタグ付けです。httpd ベースなので OS のバージョンは勝手に上がる(!) リポジトリでは、Perl のバージョンごとにディレクトリを掘っている。これを Autobuild するにはウェブからポチポチするのが必要で、バージョンを増やすたびに一つひとつ追加するのが面倒だったんだけど、GHCR なら GitHub Ac
フロントエンド刷新プロジェクトの開発サイクルを加速するデプロイパイプラインの改善 この記事は Cybozu Advent Calendar 2022 の 19 日目の記事です。 18 日目はこちら → チームメトリクスと感情データを活用した「ふりかえり」の手引き 20 日目はこちら → エンジニアとの距離が近くなっていいことたくさんだったQAの話 こんにちは!! kintone フロントエンドリアーキテクチャプロジェクト (フロリア)のAppShell チームでプロダクトオーナーをしている tasshi です。 kintone フロントエンドリアーキテクチャプロジェクト (フロリア)、およびAppShellチームについてはこちらの記事をご覧ください。 今回はフロリアの開発で利用しているテスト環境へのデプロイパイプラインを紹介します。 目次 フロントエンド刷新プロジェクトの開発サイクルを加速
今年はコロナで出かけていないので、ちょっとGitHub Actionいじってます。 やりたいこと タイトル通りですが、やりたいことは「GitHub Actionでタグを打ったときに、git-pr-releaseみたいな前のタグからのPRのリストをリリースノートに乗せたい」です。 実際の自動で生成したリリースノート やりかた これを実施するにあたり、git-pr-releaseと違ってメインブランチとサブブランチを決めてそのPRを取るという手法が使えないので以下のようにする必要があります 前のタグからの今のタグへの全コミット取得 PRのコミット取得 対象のPRを取得 リリースノートに反映 前のタグからの今のタグへの全コミット取得 これはGitHubのAPIからは取れなかったので、Git操作で取得します。 git log を使えば、あるタグから別のタグまでのコミットログを取れます。 また通常の
GitHub Actions: DRY your GitHub Actions configuration by reusing workflows actions October 5, 2021 Now available in public beta, you can reuse entire workflows as if they were an action. Instead of copying and pasting workflow definitions across repositories, you can now reference an existing workflow with a single line of configuration. Reusing workflows are great for reducing configuration. Here
SecurityIntroducing required workflows and configuration variables to GitHub ActionsNow, you can standardize and enforce CI/CD best practices across all repositories in your organization to reduce duplication and secure your DevOps processes. Today, we are introducing two new features for GitHub Actions to help standardize policies and reduce duplication, required workflows and configuration varia
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く