タグ

githubに関するkazokmrのブックマーク (7)

  • 変更履歴を記録する

    Version 1.1.0 # Changelog All notable changes to this project will be documented in this file. The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] ### Added - v1.1 Brazilian Portuguese translation. - v1.1 German Translation - v1.1 Spanish translation. - v1.1 Italian

    変更履歴を記録する
  • GitHub Actions のみで、actions/cache も使わない最軽量の VRT

    Web アプリケーション開発での VRT 導入は、ちゃんと運用するとなると以下のような多くの検討事項を伴います。 Storybook のストーリーベースで比較するか?それとも実アプリケーションの URL ベースで比較するか? CI 上でアプリケーションをビルドして dev server を立ち上げるか、それともデプロイ先のアプリケーションにアクセスするか? スクリーンショットの比較はどのように行うか?比較時の閾値はどのように設定するか? 比較元のスクリーンショットはどのように用意するか?例えば Amazon S3 などのストレージ や GitHub Actions の actions/cache を使用する場合など コミットハッシュを用いて比較元のスクリーンショットを特定する場合、マージ先のコミットハッシュに紐づくスクリーンショットが存在しない時の対応は? VRT の結果で差分が出たが、そ

    GitHub Actions のみで、actions/cache も使わない最軽量の VRT
  • 社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング

    この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的にドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

    社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
  • ECS用のCDパイプラインに対する考察

    それでは、1パターンずつ構成を確認していきます。 1. 全部GitHub Actionsでやる GitHub Actionsでパイプライン全体を構築する場合は、以下の図のような構成になります。 ちなみに、GitHubのDeploymentsを使用することで、Slackと組み合わせてのChatOpsや、任意のコミットのデプロイを実行などいろいろと便利になります。 ですが、Deployments APIをパイプラインで利用するには、Actionsのトリガーの条件を変えたり、ECSへのデプロイの成否に応じてAPIを使ってDeploymentのステータスを更新したりする処理が必要になり、少々パイプラインが複雑化してしまいます。 なので、今回の趣旨とちょっとずれているため、各パターンには記載していません。 では、以下で処理を順に説明していきます。 Image Build 図中の Build Imag

    ECS用のCDパイプラインに対する考察
  • GitHubセキュリティ Organization運用のベストプラクティス

    書ではGitHub Organizationをセキュアに運用する方法について解説します。 GitHubは大変便利なサービスで、個人利用のみならず組織で活用されるケースも多いです。しかしGitHubの初期設定は利便性重視であり、セキュリティ対策は利用者による明示的な設定が必要です。 書では意外と日語でまとまった情報がない、Organizationレベルのベストプラクティスを体系化しています。GitHub Organization管理者はもちろんのこと、ソフトウェア開発者にも有益な情報を提供します。

    GitHubセキュリティ Organization運用のベストプラクティス
  • 機密データのGitHubへの意図しないアップロードを防ぐ「Deadshot」がオープンソースで公開

    Deadshotは、すべてのコミットで実行され、正規表現を使用してプルリクエストの差分をスキャンし、重要なものを探す。重要なものが見つかった場合には、プルリクエストにコメントを追加して、指定されたSlackチャネルに通知することも可能で、特定された機密に対処することなくプルリクエストがマージされた場合には、セキュリティチームのキューに、Jiraチケットを作成する。 PythonベースのFlask-Celery-Redisマルチコンテナアプリケーションであり、GitHubアプリとしてインストールされ、インストール先のリポジトリのメインブランチに対して作成された、すべてのプルリクエストで実行される。 Flaskコンテナは、プルリクエストのペイロードを受信するためのAPIルートを公開し、プルリクエストのペイロードが受信されるとサービスはペイロードをRedisキューに転送する。また、Celeryコ

    機密データのGitHubへの意図しないアップロードを防ぐ「Deadshot」がオープンソースで公開
  • ライセンスをつけないとどうなるの? - Qiita

    GitHub上でプログラムを公開するとき、 どのライセンスを使えばいいのかわからない どうやってライセンスを設定すればいいのかわからない ライセンスというもの自体が難しそうでよくわからない などの理由で、ライセンスを設定しないままになっていることはないでしょうか? この記事では、個人の開発者によるプログラムにライセンスが設定されていなかった場合にどのようなことが起きるのか、という観点からスタートして、ライセンスについての理解を深めていこうと思います。1 注意1: この記事の執筆者は法律に関する専門家ではありません。法律やライセンスに関する言及や解釈は不正確である可能性があります。実際の問題に対しては専門家による助言を受けてください。 注意2: この記事の内容は執筆者個人の見解であり、所属企業・部門の見解を代表するものではありません。 ライセンスがないということ プログラムのソースコードは、

    ライセンスをつけないとどうなるの? - Qiita
  • 1