GitHub Actions: Introducing the new M1 macOS runner available to open source!
GitHub Actions: Introducing the new M1 macOS runner available to open source! actions January 30, 2024 Today, GitHub is excited to announce the launch of a new M1 macOS runner! This runner is available for all plans, free in public repositories, and eligible to consume included free plan minutes in private repositories. The new runner executes Actions workflows with a 3 vCPU, 7 GB RAM, and 14 GB o
.git-blame-ignore-revs ファイルを使ってgit blameの結果を綺麗に保つ
はじめに先日、関わっているプロジェクトで使っている macisamuele/language-formatters-pre-commit-hooksを長らくアップデートしていなかったのでアップデートした。 すると内部で使用しているフォーマッタのバージョンも上がり1フォーマットに微妙な差が出てしまった。 なにも考えずに差分をcommitしても良かったが、コードのフォーマット変更のコミットを追加してしまうと、後々 git blame で本来の変更コミットが追いづらくなってしまうのは避けたかった。 そこでプロジェクトに以下のような .git-blame-ignore-revs ファイルを導入することで解決した。 # This is a file used by GitHub to ignore the following commits on `git blame`. # # You can a
GitHub Actionsのワークフローを可視化するactions-timelineを作った
最初に作ったのがCIAnalyzerです。なるべくツール自体の運用の手間がかからないように常駐サーバー無し、データの保存先と可視化はマネージドサービスを使う前提で設計しました。具体的にはデータの保存先をBigQueryとすることによって自前でDBを管理する必要をなくし、webhookを受けるのではなくcronで定期的にAPIを叩くことで常駐サーバーを不要にし、データの可視化はBigQueryと簡単に連携できてマネージドサービスであるLooker Studioを使用する前提としました。 CIAnalyzerのアーキテクチャ CIAnalyzerを作ったきっかけはAzure Pipelineの分析機能に感銘を受けたことで、それと同等の分析を当時自分が業務とプライベートで使用していたJenkins, CircleCI, Bitrise, GitHub Actionsでも可能にしたいと思って開発を
組織でのはてなブログ運営をGitHub上で行うためのテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」を公開しました - はてなブログ開発ブログ
GitHub上ではてなブログ運営を可能にするテンプレートリポジトリ「HatenaBlog Workflows Boilerplate」をベータ版として公開しました。 このテンプレートをご利用いただくと、組織でのブログ運営に求められるワークフロー(下書きの作成、更新、内容のレビューや公開など)をGitHub上で行うことができます。組織利用向けに整備していますが、どなたでもご利用いただくことが可能です。 導入方法や詳しい利用方法については、上記のリポジトリのREADMEをご参照下さい。 特長など 下書きの作成時に、作成した下書きのみが含まれたプルリクエストを自動で作成します*1。コンフリクトを防ぎ、ワークフロー上の管理を容易にします GitHub Actions を利用して動作するためローカルでの環境構築が不要です。GitHub組み込みのVisual Studio Code (github.d
GitHub APIを利用したスケーラブルなマスターデータ管理システム - Mirrativ Tech Blog
こんにちは、バックエンド基盤チームマネージャーの夏（なつ）と申します。ミラティブの基盤チームはユーザが直接触れる機能よりかは、開発者や会社全体の生産性を向上させるためにエンジニア主導で課題を発見・解決している部署です。 今回は基盤チームが主体となって運用しているマスターデータ管理システムについて紹介したいと思います。ゲーム運営などではエクセルやスプレッドシートで管理されることがよくありますが、学習コストや安全性の観点で入力者を増やしづらい場合があります。このような問題に対応するため、ミラティブでは一部のマスターデータをGitHub APIを利用した専用の管理画面を実装することで入力作業をスケールできるようにしました。 （なお、本記事は社内向けドキュメントを兼ねています） マスターデータとは マスターデータとはユーザによって生成されるデータではなく、主に運営が用意するデータになります。詳細と
GMOペパボ、「GitHub Copilot」の利用データ公開 AI提案のコード、どれくらい採用？
GMOペパボは8月30日、同社が6月7日に導入したAIプログラミング補助ツール「GitHub Copilot」の利用データを公開した。6月7日から7月19日の間にAIが提案したコードの採用率などを明らかにしている。 コードエディタ「Visual Studio Code」でGitHub Copilotを活用する社内ITエンジニアのデータを集計した。期間中にAIが提案したコードの総数は約81万8000件。このうち、ユーザーがAIの提案をそのまま採用したのは全体の約28％に相当する約24万6000件だった。 「（採用されたコードの）総行数は3万5000行。採用後に修正されるケースも多々あると思われるが、1カ月弱で3万5000行のコードを書く時間と手間を削減できたと考えると、期待する効果が得られているのではないか」（同社） 言語別の採用率も公開した。例えばRubyでは5454件（採用率28.7％）
Terraform で実現する効率的な GitHub 権限管理 - カミナシ エンジニアブログ
こんにちは。ソフトウェアエンジニアの坂井 (@manabusakai) です。 今月でカミナシに入社してちょうど 1 年が経ちました。前職では 6 年間 SRE チームにいたのでプロダクト開発はブランクがありましたが、さまざまな挑戦をさせてもらっていたらあっという間に 1 年が経っていました。 カミナシのエンジニアリング組織もこの 1 年で急拡大しており、入社当初から比べると正社員のエンジニアも倍以上に増えました。 GitHub の権限管理、どうしていますか？ ところで、みなさんが所属されている組織ではどのように GitHub の権限管理を行なっていますか？ カミナシではつい先日まで、ほとんどのエンジニアが Organization の Owner 権限を持っていました。理由は、メンターになったエンジニアがニューカマーのユーザーを招待していたからです。 しかし、統制が取れていないことでいく
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 - Classi開発者ブログ
GitHub Actions と Release Please を使ったアプリケーションのリリース自動化 こんにちは @lacolaco です。最近は、先日プレスリリースが出された「学習トレーニング」機能を裏で支えているコンテンツ管理システム（以下内部CMS）の開発に携わっています。 corp.classi.jp この記事では、内部CMSのフロントエンド（Angular アプリケーション）のリリースフローを自動化している仕組みを紹介します。現在のリリースフローの全体像は次の図のようになっています。この中にある Release Please というのが、今回特に紹介したいツールです。いくつか日本語でのブログ記事などもあるので特にマイナーというわけではないと思いますが、多くの場合はライブラリのリリースに使われています。一方、アプリケーションのリリースで使っているケースはあまり発信されてないよう
社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
コンテナのセルフホストランナーの中でコンテナを使えるようにするrunner-container-hooks
以前にセルフホストランナーの知られざる機能であるジョブの前後に任意のスクリプトを実行できるhookを紹介しました。 今回はセルフホストランナーの知られざる機能の紹介第二弾としてactions/runner-container-hooksを紹介します。 runner-container-hooksは2023年現在では比較的新しい機能で、自分もいつ頃に知ったのかは覚えていないのですが、actions/runnerのリポジトリには2022年の4-5月頃に追加されていたようです。実装のpull-reqから少し遅れて5月には設計ドキュメントと言えるADRのpull-reqが出されています。 このADRを見たところ自分がセルフホストランナーを運用する上で今まではどうしても不可能であったコンテナの中で起動したセルフホストランナーの中でコンテナ型のactionなどが実行できないという制約を突破できることが
gh auth loginで作成されたクレデンシャルだけで生活するためにgh-doを作った - Copy/Cut/Paste/Hatena
やっとgh auth loginで得たクレデンシャル（OSのセキュアストレージに保存されているもの）のみを使う生活になったぞ— k1LoW (@k1LoW) 2023年5月15日 GitHub CLIの gh auth login で作成されたクレデンシャルはOSのセキュアストレージに保存されるようになりました。 次のエントリが詳しいです。 blog.kyanny.me 「じゃあ、もう全部セキュアストレージに保存されたクレデンシャルを使えばOK」となるのですが、なかなかそうはいきません。 なぜかというとGitHubのクレデンシャルを使うツールによって環境変数の扱いが異なるからです。 GitHubのクレデンシャル設定の歴史（私の記憶版） 注意: 以下は、あくまで私の記憶であって実際と異なるかもしれません。 前史 GitHub CLI（ gh ）やGitHub Actionsの登場以前は、クレ
GitHub のインターフェースを拡張できる「GitHub Blocks」が Technical Preview となっていました | DevelopersIO
こんにちは、CX事業本部 Delivery部の若槻です。 以前に GitHub Next について紹介をしました。 その GitHub Next のプロジェクトの1つである GitHub Blocks では、GitHub Repository 上のドキュメントの表示や検索、編集のインターフェースを拡張できるドキュメントブロックが提供されます。 GitHub Blocks 今回は、今まで Waitlist ステータスだった GitHub Blocks が先日に Technical Preview となり、誰でも使えるプロトタイプが公開されていたので触ってみました。 プロトタイプにアクセスする GitHub Blocks トップページより、プロトタイプにアクセスできます。 初サインインの場合は Blocks (GitHub Next) へのアクセスを求められます。 プロトタイプにアクセスできま
jq が jqlang organization に移譲されました - プログラムモグモグ
JSONを操作するコマンドラインツールであるjqは、これまでオリジナル作者であるStephen Dolan氏 (@stedolan)のリポジトリ(github.com/stedolan/jq)で管理されていました。 メンテナンスはNico Williams氏 (@nicowilliams)とWilliam Langford氏 (@wtlangford)の二名が行なっていましたが、近年は活動が減っておりメンテナンスが滞っていることが度々指摘されていました。 最新のリリースは2018年11月に行われた1.6であり、その後に様々なバグ修正やパフォーマンス改善、新機能の実装が行われているのにリリースされておらず、またissueやPRも放置されがちになっていました。 さらにCI (AppVeyor)は常に落ちるので、簡単なドキュメント修正でもCIが通らず苦情が来る、数か月放置されたPRは作った人が諦
More secure private attachments
May 9, 2023 Previously, all attached (drag-and-dropped) images and videos on GitHub Issues, Pull Requests, Discussions, and wikis were available to view without authentication if you knew their direct URL. Now, future attachments associated with private repositories can only be viewed after logging in. This doesn’t apply retroactively to existing attachments, which are obfuscated by having a long,
GitHub Actionsにおける設定ミスに起因したGitHubスタッフのアクセストークン漏洩
(You can read this article in English here.) 免責事項GitHubはBug Bountyプログラムを実施しており、その一環として脆弱性の診断行為をセーフハーバーにより許可しています。 本記事は、そのセーフハーバーの基準を遵守した上で調査を行い、その結果発見した脆弱性に関して解説したものであり、無許可の脆弱性診断行為を推奨することを意図したものではありません。 GitHub上で脆弱性を発見した場合は、GitHub Bug Bountyへ報告してください。 要約GitHub Actionsのランナーのソースコードをホストするactions/runnerリポジトリにおいて、セルフホストランナーの使用方法に不備があり、結果としてGitHub Actionsに登録されているPersonal Access Tokenの窃取が可能だった。 このトークンはGit
GitHub に漏れ出た内部コードを探す ~ 上場企業 3900社編 ~ - ぶるーたるごぶりん
全１回、このシリーズは今回で最後です！ TL;DR 上場企業 3900 社程に対して、すごく大雑把な「内部コード等の漏洩調査」を GitHub 上で行った 結果としては、重要度の高いものから低いものまで 10社ほどで漏洩が確認された 重要度の高いものとして、社外秘っぽそうなスプレッドシート、社員のハッシュ化パスワード(BCrypt)、 AWS Credential 等 「大雑把な」調査を行ったが、より精度の高い方法等について記事内にて触れていく 脅威インテルとか DLP みたいなエリアとかも、外部企業とかに頼るだけじゃなく「自分たちでも」頑張ってみるのがいいんだと思います GitHub Code Search ... すげえぜ！ Google Dorks ならぬ、 GitHub Dorks + GitHub Code Search でまだまだいろいろできるはず。 はじめに チャオ！ 今回は
フィッシングサイト自動テイクダウンの手法
はじめに 日常的なインシデント調査を効率化するために、自動化による分析は、フィッシング詐欺の分析者にとって重要な課題となっています。 クラウドベースの技術は、効率的にフィッシング詐欺の分析を自動化するための良い解決策です。 今回は、クラウドサービス上でのフィッシング詐欺分析とGoogle Safe Browsing(GSB)を活用した自動テイクダウンの方法について解説していきます。 フィッシングキットの解析結果についてこちらで更に詳しく解説しています。 対象読者 インフラ管理者 DevOpsエンジニア 脅威ハンター フィッシング攻撃の流れ よくあるフィッシング詐欺の流れを以下に示します。 攻撃者はホスティングサーバーを購入する 購入したサーバにフィッシングキットをアップロードしセットアップする 動作確認を完了させた攻撃者は潜在的な被害者に大量のフィッシングメールを送信する 被害者はフィッン
GitHub Actions: Deprecating save-state and set-output commands
GitHub Actions: Deprecating save-state and set-output commands actions October 11, 2022 24-July-2023 Update: Our telemetry shows significant usage of these commands so we have decided to postpone the removal. To learn more, visit the latest changelog post. To avoid untrusted logged data to use save-stateand set-output workflow commands without the intention of the workflow author we have introduce
GitHub Actionsを使ったDDoSに巻き込まれた - 私が歌川です
事例集です。 きのう、GitHubの通知を見たら、個人のリポジトリに My First PR というタイトルのPRが来ているのに気づいた。PR出すところを間違えたのかな、と思って見てみたがどうも様子がおかしい。 prog という名前のバイナリファイルを置いている .github/workflows/ci.yml*1の中身をガッと書き換えている on: [pull_request] でworkflowを起動している 20並列でjobが走るようにmatrixを設定している fail-fast: false なので、どれか1つのmatrixが失敗しても他のジョブは続行される base64 encodeした文字列をdecodeしてevalしている ドメインの名前解決を行ったあと ./prog を実行するコマンドにdecodeされた PRをめちゃくちゃな回数closeしてreopenしている PRを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
curlを使ってGitHubで発行したPATの作成者とスコープを確認する