You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
こんにちは、CX事業本部 IoT事業部の若槻です。 GitHub Actionsでは、CI/CDでよく使われる処理がActionsとして公開されており、Workflow内で自由に使うことができます。 GitHub Marketplace · Actions to improve your workflow 今回は、actions/setup-nodeを使用してWorkflowの実行時にnode_modulesをキャッシュできるのか試してみました。 actions/setup-nodeとは actions/setup-nodeを使用すると、指定したバージョンのNode.js distributionのダウンロードおよびキャッシュをしたり、npm/yarn/pnpm dependencyをキャッシュしたりすることができるようです。 actions/setup-node: Set up your
ProductSupercharging GitHub Actions with Job SummariesYou can now output and group custom Markdown content on the Actions run summary page. The same familiar functionality that powers pull requests, issues, and README files has come to GitHub Actions! We’re thrilled to announce GitHub Actions Job Summaries, which allow for custom Markdown content on the run summary generated by each job. Custom Ma
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
Slack が提供する GitHub Action "slack-send" を使って GitHub から Slack に通知するGitHubSlackslackapislack-apiGitHubActions こんにちは、Slack で公式 SDK 開発と日本の DevRel を担当しております @seratch と申します。 この記事では、私もその一員である Slack の Developer Relations チームが開発・メンテナンスしている GitHub Action である "slack-send" の使い方を日本語で紹介していきます。 この GitHub Action には三つの使い方がありますので、それぞれ解説していきます。 Incoming Webhooks で Slack に通知する chat.postMessage API で Slack に通知する ワークフロー
こんにちは。スターフェスティバル株式会社の ikkitang です。 さて、皆様 GitHub Actions 使ってますか? 弊社では大半のプロジェクトで GitHub Actions が活用されていて、 月 1 回の WinSession で知見が共有されたりしています。 GitHub Actions の素敵な所はイベントの柔軟さだと感じています。それによって GUI での操作が想起できて、直感的にイベントをフックさせて Workflow を作っていくことができます。とはいえ、Workflow が増えてくると別の Workflow をコピペで持ってきて必要な Step を書き換えるなんてことをすることがないでしょうか。 そこで、今回は Workflow の保守性を上げるために Step の共通化について調べてみました。 ちなみに今回説明にあたって GitHub にサンプルを用意してみま
これまで、GitHub Actions の手動トリガー(workflow_dispatch)では、入力値を扱う際、github.event.inputs.foo のように event コンテキストから値を取り出す必要がありました。 以前紹介した再利用可能ワークフロー(workflow_call)では、入力値を inputs.foo のように inputs コンテキストから取得します。 このようにトリガーの種類によって入力値の扱いが異なると、両方のトリガーで起動するワークフローが書きづらい問題があります。 先日この問題を解消するリリースが行われ、手動トリガーと再利用可能ワークフローの入力値の扱いが統一されました。 GitHub Actions: Inputs unified across manual and reusable workflows | GitHub Changelog 現在で
Cloud Run with IAPを利用しているアプリを開発中にPull Requesのレビューをする時、専用の環境で動作確認したいと言われたので、考えてみた。 Cloud Runには Revision Tagを利用して、任意のRevisionにRequestを送る独自URLを発行する機能 があるが、IAP(Identity Aware Proxy)を利用している場合、Serverless NEGを利用して、HTTP LBからRequestを受けるため、この機能を使っただけでは解決しない。 最終的なCloud Runの構成 作る時に考えたこと 前提 Identity Aware Proxyがかかっている MarkdownをHTMLに変換しているStaticなWeb Site 開発チームは数人 更新頻度はそんなに高くはない 対象はIAPをかけているStaticなWeb SiteでPull
GitHub AcionsのVM上でTailscaleをセットアップすると、Tailscale経由でGitHub ActionsのVMにsshできます。 Tailscale知らない人へ 事前準備 サンプルworkflow 何が嬉しいか コツ 他の選択肢 Tailscale知らない人へ Tailscaleが何かご存じない方は、過去に記事を書いているのでそちらを参考にしてください。 mstshiwasaki.hatenablog.com 事前準備 Tailscaleのアカウントを取っておくこと 作業用のPC/MacでTailscaleをセットアップしておくこと GitHub ActionsのSecretsで SSH_APIKEY SSH_PUBKEY という名前でログインに使うsshの公開鍵を登録しておくこと サンプルworkflow 事前準備が出来たら、まずは試してみましょう。GitHub
11/10に突如素晴らしいアップデートが来たので、興奮冷めやらぬうちに公式よりちょっとだけ詳しい解説を書きます。 GitHub Actionsは素晴らしいCI/CDサービスであり、特にpush, pull-request, その他あらゆるGitHub上の行動をトリガーにしてワークフローを起動させる設定を簡単に書くことができます。しかし、手動でワークフローを起動させる機能の追加は他のトリガーに比べて後発でしたし、パラメータを入力するための機能やUIが少々貧弱と言わざるを得ないものでした。 一方、古より存在するJenkinsはpush, pull-requestなどの自動トリガーを設定するのは難易度が高かった[1]反面、手動でジョブを起動する機能やUIは充実していました。基本の自由テキスト以外に、プルダウンによる選択、booleanのチェックボックス、Jenkinsに登録したシークレットからの
1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。
2021/01/017 追記 : Android 版も書きました! 追記 2021/01/22 コードが間違っていたので修正。 それとビルドネームが github_actios_sample とタイポしていることに気づいた。これはプロジェクトを作る時にミスってしまったらしい。 はじめに Flutter build iOS して Xcode で archive してそれをまた App Store Connect にアップロードして...という作業は面倒くさい。GitHub Actions を使えば push などをトリガーにこのやっかいな作業を自動化してくれるというじゃあないか。しかも、パブリックリポジトリなら無料で使わせていただけるという。これはもう、やるしかない。 すでに周辺知識がある人に向けて main.yml をはじめに載せておく。 いろいろ設定はできるが極力シンプルな形にまとめた。
【GitHub Actionsをもっとたくさん使いたい!】AWS CodeBuildでSelf-hosted RunnerできるようにしたAWSCIDockerCodeBuildGitHubActions GitHub Actionsとても便利ですよね。 コミットプッシュやPRマージだけではなく、Issueコメントやラベル追加をトリガーにしてワークフローを動かすことができるので、いろいろな定形処理を自動化できます。 あれもこれもといろいろなワークフローを追加したら、利用時間上限になってしまってワークフローのダイエットしないといけなくなった、、、なんてことも。 今回はそんなGitHub Actionsを、(有料だけど)もっとたくさん使えるようにと作った仕組みについての紹介です。 作った動機 主な理由としては1の時間のかかるジョブが増えてきたことですが、2や3の運用コスト、費用面でもメリットが
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く