GitHub Actionsで定期実行（cron）のワークフローを組んだユーザーが退職すると、ワークフローは無効化される 大事なことなので、見出しでも同じことを書いてしまいました。 何を言っているんだという感じですが、とにかくそういうことらしいです。 厳密には最後にワークフローにコミットしたユーザーが組織から削除されると、無効になるようです。 GitHub Actionsの定期実行でPR作成を自動化*1している会社もそれなりにあるかと思うのですが、その場合はそれらが全部停まります。 さらに、1度無効化されてしまった場合はcron式を変更しないといけないというのも罠ポイントですね。 最後にワークフローの Cron スケジュールにコミットしたユーザーが組織から削除されると、スケジュールされたワークフローは無効になります。 リポジトリへの write アクセス許可を持つユーザーが Cron スケ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに GitHub Actionsを使い込んでいると、リファレンスに明示されていない部分が気になることが多々ある (個人の見解です) 。 タスクに忙殺されていると「動くから良し」の判断のもと、碌な検証や検討がされていない不適切な実装のままWorkflowが運用されてしまうこともしばしばある (個人の見解です) 。 より深くGitHub Actionsの仕様を理解し、より適切に実装するということがスムーズに行えるよう、調査と結果をこの記事に記録する。 検証環境はGitHub Enterprise Server 3.14.4 である。g
Event https://testnight.connpass.com/event/311263/ Archive https://youtu.be/96KUNLiMe6w?t=327
はじめにみなさん、GitHub Actionsは利用していますか。 先日、Github actionsのコストパフォーマンスについて検討していた以下の記事が少し話題になっていました。 この記事のデータによると、単純な料金の比較ではFargate Spotを利用してセルフホストランナーを起動するのが圧倒的にコストが低くなるということがわかります。 2022年12月現在、Fargate SpotはEKSに未対応で対応していないため、利用するためにはECSでないといけません。そのため、EKSでオートスケールするので有名な actions-runner-controller ではFargate Spotは利用できません。 そこで思いつきました。ECS上でFargate Spotを利用してオートスケールする仕組みを作れば、より安くセルフホストランナーを利用することができるのではないか、と。 初めにE
はじめに こんにちは、サイボウズ24卒の@yuasaです。 サイボウズでは開発・運用系チームに所属する予定の新卒社員が研修の一環として、2週間を1タームとして3チームの体験に行きます。新卒社員の私が生産性向上チームの体験に行った際に、チーム内でGitHub Actionsを利用する際の脅威と対策について調査を行い、ドキュメント化した上で社内への共有を行いました。本記事では、そのドキュメントの一部を公開します。 対象読者 本記事の主な対象読者としては、以下のような方を想定しています。 GitHub Actionsを組織で利用しているが、特にセキュリティ対策を実施していない方 GitHub Actionsを組織で利用しており、部分的にセキュリティ対策を実施しているが、対策が十分かどうか分からない方 本記事がGitHub Actionsのセキュリティ対策を検討する上で参考になれば幸いです。 本記
『GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用』という書籍を最近出版したので紹介します。本書ではGitHub Actionsの実装と、CI/CDの設計・運用を体系的に学べます。一粒で二度美味しい書籍です。筆者個人としては「実践Terraform」以来、4年半ぶりの商業出版になります。 gihyo.jp どんな本？ GitHub利用者にとって、もっとも導入が容易なCI/CD向けのソリューションはGitHub Actionsです。GitHub Actionsの活用事例は多く、検索すればたくさん情報が出てきます。ただ断片的な情報には事欠かない反面、体系的に学習する方法は意外とありません。CI/CD自体がソフトウェア開発の主役になることもまずないため、なんとなく運用している人が大半でしょう。そこで執筆したのが『GitHub CI/
The GitHub Blog の記事 Enabling branch deployments through IssueOps with GitHub Actions を読んで「branch deployments（ブランチデプロイ）」というデプロイ戦略を知った💡 プルリクエストを main ブランチにマージしてから本番環境にデプロイするのではなく，プルリクエストを直接本番環境にデプロイして，動作確認の結果問題なしと判断できてからプルリクエストを main ブランチにマージするという流れが特徴的❗️そして，デプロイに異常があってロールバックする場合は main ブランチをデプロイして復旧する💡 記事に載ってるブランチ画像（Merge Deploy Model と Branch Deploy Model）は非常にわかりやすく見てみてもらえればと〜 github.blog IssueOp
はじめに GitHub ActionsでGitHub Appsを使うときには登録時に入手できるApp IDとsecret keyから一時的に使用できるトークンを発行する必要があります。 このトークンはGitHubが用意しているRest APIやGraphQL APIに対してリクエストすることによって入手することができます*1が、いちいちAPIを叩く準備をするのは面倒なので個人が作成したActionであるtibdex/github-app-tokenやSentryが提供しているActionであるgetsentry/action-github-app-tokenを使うことによって楽をすることができました。 今まで非公式なActionに依存していたトークン生成ですが、GitHubが公式でAppsトークンを作成するActionであるactions/create-github-app-tokenを提
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
文字セットと照合順序 MySQLに限らず多くのRDBMSには文字をどのようにバイト列で表現するかを決めるルールである文字セットがあります。 また文字セットに対応して文字同士を比較するときのルールである照合順序*1という概念があります。MySQLの場合、この照合順序は1つの文字セットに対して複数存在する概念です。なのでそれぞれの文字セットに対してデフォルトの照合順序があります。 照合順序が何に設定されているのかを把握していないと思わぬ結果を招くことになり、有名なのが寿司ビール問題と呼ばれるものになります。これは寿司の絵文字とビールの絵文字がMySQLのutf8mb4_general_ciという照合順序の下で等価であると判定されることが原因です。 blog.kamipo.net ここまで照合順序の話をしましたが間違ったことを話している可能性があるので公式ドキュメントを参照してください。 dev
大分時間が経ってしまいましたが、2022/8/31 に開催された stand.fm 主催の TECH STAND #9 GitHub イベントに参加しました。 その際に呟いたやつが今回の記事の内容です 有り難いことに直ぐにフォロー頂きました。 あまり纏まった記事が見当たらなかったので、自分用のメモとしてまとめます。 他のCIにはあったアレ GitHub Actionsを利用する前は、TravisCIやCircleCIを利用していました。 移行してから随分使ってないので、記憶が定かではないのですが という機能が標準であった気がします。 この機能の名前は何と呼ぶのでしょうか？地味だけれども、ないと困るアレですｗ GitHub Actionsのリリース直後にこちらの機能と [ci skip] が使えずに後発なサービスなのにーと不満を覚えていました。 その後にアレの機能を実装したカスタムアクション
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
この記事は、 NTT Communications Advent Calendar 2022 16日目の記事です。 はじめに こんにちは、イノベーションセンター テクノロジー部門の池田です。 普段はSkyWayというプラットフォームを開発しています。 この記事では、GitHub ActionsからGoogle Cloud Platform(以下GCP)のCloud FunctionsにPipenvを利用したPythonアプリケーションをデプロイした際の話をGitHubのEnvironmentsなどに触れつつ紹介したいと思います。 モチベーション SkyWayで使うPythonのアプリケーションをクラウド上にデプロイしたかったのですが、毎度手動でデプロイするのはもちろん面倒です。 また、自動化した場合でもproduction,stagingなどの環境ごとに条件分岐を書いたり、意図しない自動デ
『Composite Action実践ガイド』はGitHub Actionsに関心のあるソフトウェアエンジニア向けのZenn Bookです。 本Bookでは「Composite Action」の実運用で役立つプラクティスを紹介します。テスト・静的解析・セキュリティ・ドキュメンテーション・依存関係管理・リリースマネジメント・Reusable Workflowsによる開発体験の向上など盛りだくさんです。 Composite Actionはシンプルなので、ただ実装するだけなら難しくありません。しかしメンテナンス性を高め、一貫性を維持するのは難しい仕事です。さらに利用者に優しく使いやすいものを提供するには、高いホスピタリティも求められます。 そこで本BookではComposite Actionの利便性を高め、持続的に進化させるためのアイデアをたくさん散りばめました。Composite Action
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
maku693です。 Github ActionsでPuppeteerを簡単に使えるCustom Actionを作りました。 github.com 最近Github Actions上でブラウザを動かしたくなったのですが、いちいち実行環境を整えるのも面倒なので、サクッとできないものかと調べたところ、意外とPuppeteerをそのまま使えるactionというのは存在しないようだったので、自分で作りました。 使い方はREADMEに書いてありますが、ここでも軽く紹介します。 以下のjobでは、ページのタイトルを取ってきて、それを後続のstepで利用しています。 - id: get-title uses: maku693/action-puppeteer-script@v0 with: script: | const page = await browser.newPage(); await pag
Motivation This module creates the AWS infrastructure to host action runners on spot instances. It provides lambda modules to orchestrate the life cycle of the action runners. ランナーは Spot Instance 上でホストしている Spot Instance のスケールアップ/ダウンはLambdaで制御 なぜ、Lambda を選んだのか？ AWS, GitHub に最小限のアクセスで小さなコンポーネントが作成できるため Repository レベルで動作し、Organization レベルまでスケールする、最小限のコストでスケーラブルなセットアップを提供できるため Kubernetes を選ばなかった理由は？ W
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
