今回は、Git/Githubでマジでしたら終わることについて紹介したいと思います。(実務で自分が怒られたこと中心) 初心者向けの備忘録なので、初めたてじゃないよって人は読まなくていいかもです。 master/mainブランチのまま変更する or masterにpushする これまじやばいです。自分の変更がmasterと同期するってことなので、conflict発生したら詰みます。 あと破壊的な変更を戻せなくなります。
あなたのパフォーマンスを倍にする Frontend Ops はいかがですか.md あなたのプロジェクトに Frontend Ops を。 [経営者の方へ] ウェブサイトが遅くなっていませんか?機能追加が遅くなっていませんか? 私 @mizchi は Node.js とフロントエンドのエキスパートです。もし私を知らなければ、御社のフロントエンド担当に mizchi とは誰か聞いてみてください。それが一番早いと思います。 Frontend Ops の専門家として御社のプロダクトの改善にご協力します。 Frontend Ops は、ウェブサイトのロード時間を改善したり、開発者の基盤に手を入れることで一日に何度機能を追加できるかという指標に貢献するロールです。その結果としてUXを改善し、ビジネスを前進させます。 成果報酬で、費用はざっくり 100万円*達成率 となります。(詳細は後述) 弁護士作成
GitHub Actions の実践的なノウハウが凝縮されている一冊「GitHub CI/CD 実践ガイド」を読んだ📕 本書ではソフトウェア開発ライフサイクルから GitHub Actions 基礎トピック・GitHub Actions 実践トピックが紹介されていて,さらに GitHub Actions を活用して実現するリリース自動化・パッケージ管理・セキュリティのシフトレフトまでもカバーされている❗️素晴らしい👏 GitHub Actions をなんとなーく使っていたり,いつも既存のワークフローをコピーしていたりする人は必読かなと \( 'ω')/ また著者の経験に基づくベストプラクティス(こうすると良いよ〜的な)が散りばめられているのも現場目線で読めて良かった❗️ GitHub CI/CD実践ガイド――持続可能なソフトウェア開発を支えるGitHub Actionsの設計と運用 エ
Azure Portal から GitHub リポジトリを指定して Static Web Apps を作成すると自動的にワークフローが作成されますが、作成されたワークフローは Deployment Token を使うようになっています。 この Deployment Token を使う方法は非常にシンプルで扱いやすく、立ち位置としては App Service の Publish Profile と同じもので単一 SWA へのデプロイのみ可能なものです。作成されたワークフローでは公式の GitHub Action を使うため、ビルド含めすべて自動でやってくれるのでお手軽です。 シンプルに 1 つの SWA へのデプロイであればそこまで困らないのですが、モノリポで複数の SWA へのデプロイを行う場合には Deployment Token の管理が煩雑になるため、App Service や Az
チューリング完全とは、ざっくり説明すると、一部を除くほとんど全ての計算が可能な能力を意味します。言い換えると、ほとんど全ての計算問題を解く能力を意味します。(あとでもう少し詳しく説明します。)プログラミング言語は一般にチューリング完全であり、例えば TypeScript や Python はチューリング完全です。プログラミング言語以外にも、TypeScript の型システムやスーパーマリオメーカー、マジック・ザ・ギャザリングもまたチューリング完全であることが知られています[1][2][3]。直近では find と mkdir だけでチューリング完全になると報告されていましたね[4]。 逆にチューリング完全でない例としては正規表現[5]があります。チューリング完全ならば正規表現で解ける問題を全て解けますが、その逆は不可能です。例えば回文の判定は正規表現だと無理です。このように、数ある計算能力
Github Actionsとは リポジトリ内で処理を自動化してくれる機能になります。 CI/CDに使うことが多いですが、使い方次第では無限大の可能性があります。 また、自分自身で作るだけでなく世界中のエンジニアが公開しているGithub Actionsを使用して自分のプロジェクトで自動実行することも可能です。 エンジニアは基本面倒くさがり屋です。 だからこそGithub Actionsで徐々に自動化して楽なコーディングライフにして欲しいです。 自動化する処理 今回はあると便利な下記2つをGithub Actionsで自動化していこうと思います。 GithubActions処理状況をSlack通知 プルリク作成時にテスト 詳細な処理やコードは次で書いていきます。 実装 実装内容的には簡単ですので是非導入を考えて見てください。 今回はGithubActionsの他にactions/toolk
はじめに こんにちは、セキュリティエンジニアのJJ (yuasa)です。今回はGitHub Actionsのワークフローにおける脅威検知ツールであるtracee-actionを触り、検知ルールの書き方について見ていきます。なお、tracee-actionは2024年7月時点で本番環境での利用は想定されていない点にご注意ください。 This project is not production ready. We are experimenting with it to test and demostrate Tracee capabilities. tracee-action tracee-actionはTraceeを用いてGitHub Actionsのワークフローにおける脅威を検知します。TraceeはeBPFを用いてLinuxランタイム上でのシステムコールを検出することができるツールです
2024-07-24 追記: 本記事の続きで、開発組織でのソフトウェア開発の Issue や PR を自動で適切な GitHub Project に割り当てていく方法についても書きました。 https://zenn.dev/shunsuke_suzuki/articles/manage-enterprise-issue-pr-by-project タイトルの通り、自分が管理する全 OSS の Issue や Pull Request (以下 PR) を 1 つの GitHub Project に集約した話を紹介します。 自分は様々な OSS をメンテしており、様々なリポジトリで作られる GitHub Issues や PR を日々ハンドリングする必要があります。 しかしこれだけリポジトリの数が増えると一つ一つリポジトリを巡回してハンドリングしていくのは困難です。 ユーザーによって issu
はじめに さくらインターネット SRE室の久保です。 今日は「terraform (plan|apply) in GitHub Actions」というタイトルで発表させていただきます。 今日発表する内容は、画像で表すと上図のようになります。誰かがPull Requestを送ると、それをもとにGitHub Actionsを動かし、Terraformのplanやapplyを動かして、自動的にTerraform管理下にあるリソースを更新してくれる、そういう仕組みを作ったという話です。 terraform (plan|apply)を実行する際のポイント Terraformのplanとapplyを実行する際のポイントとして、まず各種秘匿情報、具体的にはAPIキーなどが必要になるので、実行結果をチーム内で共有してレビューするのが結構面倒です。何らかの方法でAPIキーを共有して使うにしても、あるいは各自
GitHubでは削除されていたりプライベートに設定されていたりするフォークやリポジトリに誰でもアクセスでき、さらにその動作が欠陥ではなく仕様通りであるとオープンソースセキュリティ企業のTruffle Securityがブログに投稿しました。 Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co. https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github GitHubでの一般的なワークフローとして、「新しいフォークを作成する」「コミットする」「フォークを削除する」というものを考えてみます。 この時、削除したはずのフォークの中身を誰でも確認できてしまうとのこと。
こんにちは。スタディサプリのQAチームです。 今回のBlogではスタディサプリで実施している自動化テストの一部の取り組みについて紹介させていただきます。 なお、スタディサプリQAチームの特性を活かし、本記事については日英中3言語で記載します。より多くのオーディエンスに読んで頂ければ嬉しいです。 自動化する動機 まず、なぜ自動化テストを導入するのでしょうか。 1. 新規機能が追加される度に、既存機能への影響を確認するための回帰テストをしなければなりません。 2. 繰り返し同じテストを手動実行することにより、テストコストが増加します。 3. 人間が実施すると、人為的ミスによる不具合の検出漏れが発生してしまう可能性が否定できません。 そのため、品質を担保した上でより早くリリースすることを目的とし自動化を導入しました。 現在の開発およびテストフロー QAが回帰テストの自動化テストスクリプトをGit
GraphRAG: New tool for complex data discovery now on GitHub Published July 2, 2024 By Darren Edge , Senior Director Ha Trinh , Senior Data Scientist Steven Truitt , Principal Program Manager Jonathan Larson , Senior Principal Data Architect Earlier this year, we introduced GraphRAG (opens in new tab), a graph-based approach to retrieval-augmented generation (RAG) that enables question-answering ov
ワークフローの概要 このGitHub Actionsワークフローは以下の主要な機能を持っています: 新しいイシューが開かれたときに自動的に起動 イシューの内容を分析し、不適切なコンテンツをチェック 既存のイシューとの重複を検出 必要に応じてラベルを付与 ワークフローの詳細解説 トリガーとパーミッション設定 name: Issue Review on: issues: types: [opened] permissions: issues: write contents: read このセクションでは、ワークフローの名前を定義し、トリガー条件とパーミッションを設定しています。 on.issues.types: [opened]: 新しいイシューが開かれたときにワークフローが起動します。 permissions: ワークフローがイシューの読み書きと、リポジトリコンテンツの読み取りを行うための権
GitHub、ArmベースのLinux/Windowsランナーをパブリックベータで公開。x64ランナーより37%安価に GitHubは、GitHub上でソースコードのビルドやテストなどのさまざまな処理を行えるGitHubホステッドランナーとして、ArmベースのLinuxとWindowsのランナーをパブリックベータとして公開しました。 Did you know that our new Arm-hosted runners can decrease your carbon footprint? Learn more about how you can start using Arm-powered runners today! https://t.co/xa01sYA6yk — GitHub (@github) June 3, 2024 Armベースのランナーを利用することで、Armベースの
継続的にメンテナンスするのではなくて、雑な使い捨てでいいならshellscriptとjq職人芸でいけるので頑張ってしまったけれど、継続的にやるならもっと違うもので書いた方がメンテナンスしやすいと思います。 細かい部分はいくらでも改善の余地があるとは思いますが、とりあえず動いたのでヨシ・・・!? 以前も多少似たような何か作ったけど、こういうの誰か既にもっと綺麗に作ってないんですかね。 xuwei-k.hatenablog.com GitHub Actionsのログはデフォルトでは90日保存されてるはずなので、その程度の期間をなんとなく集計したいだけならば、こうやって後から集計するだけで十分ですね。 もちろん、yamlの内部の構造がすごく変わっていると集計が難しいか実質不可能になるリスクはありますが。 もっとしっかり計測したいならば、buildした時点で専用の場所に綺麗に記録して、他のもっとリ
Googleは内部ドキュメントを誤ってGitHubに公開し、Apacheライセンスが恒久的に付与された ー そんな珍事が、SEO業界を中心としたWebの世界を大きく揺るがせている。 特に、過去の説明との矛盾がSEO専門家たちの怒りを大きく買っているようだ。 Googleは内部の技術文書をGitHubに誤って公開し、その文書には検索エンジンがウェブページをランク付けする方法の一部が詳細に記載されている。 (そのコードを元に公開されたWebサイト) この情報はSEOコミュニティにとって驚きであり、過去にGoogleが提供した情報と矛盾する部分も含まれている。 公開されたドキュメントの内容 技術文書の詳細: 公開されたドキュメントには、Googleの「ContentWarehouse」に関するAPIドキュメントが含まれている。これには2,596のモジュールと14,014の属性が記載されており、検
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く