タグ

articleとCIに関するefclのブックマーク (5)

  • npm installとnpm ciの動作確認を簡単にやっておいた - Mitsuyuki.Shiiba

    先週、npm installとnpm ciについて調べて考えたことを書いたのだけど、ドキュメントを読んで、頭の中で考えたことをまとめただけなので、これだけだとちょっと気持ち悪いなと思って。簡単ではあるけど実際の動作を確認することにした。 bufferings.hatenablog.com 結果 だいたい想像どおりだった。今回のサンプルプロジェクトで実験した結果は次のとおり。 (1)と(2)は、キャッシュがない場合のnpm ciとnpm installの速さ。想像では「npm ciの方が多少速いのかな?」と考えていたけどほぼ同じだった。node_modulesがない状態から始まるので、npm ciはnpm_modulesを削除する必要がない。一方で、npm installも既存のnode_modulesをチェックする必要がなくて、package.jsonとpackage-lock.jsonの

    npm installとnpm ciの動作確認を簡単にやっておいた - Mitsuyuki.Shiiba
    efcl
    efcl 2023/03/22
    npm installとnpm ciとキャッシュについて。 `npm install`は`node_modules/`を再利用できるが、安全ではないケースもある。 `npm ci`は`node_modules/`を削除するため`~/.npm`をキャッシュとして使う必要があることについて。
  • サプライチェーンセキュリティにおける脅威と対策の再評価 | メルカリエンジニアリング

    ブログの主旨 サプライチェーンセキュリティにおいて既存のフレームワークよりも具象化されたモデルを用いて脅威及び対策を精査することで、実際のプロダクトへのより実際的な適用可能性及び課題を検討した。 具象化されたモデルにおいては「脅威の混入箇所と発生箇所が必ずしも一致しない」という前提に立ち、各対策のサプライチェーンセキュリティにおける位置付け及び効力を検討した。とりわけ、ともすれば無思考的に採用しかねないSBOM等の「流行の」対策に対して、その課題や効果の限定性を明らかにした。 これらの脅威分析に基づき、「サプライチェーンの構成要素に存在する多数の開発者それぞれに対して責任を分散して負わせる」形態のパイプラインを置き換えるものとして、「各構成要素に存在する開発者に対して一定の制約を強制する代わりに、サプライチェーンセキュリティに関するオペレーションを一点に担う中央化されたCIパイプライン」

    サプライチェーンセキュリティにおける脅威と対策の再評価 | メルカリエンジニアリング
    efcl
    efcl 2022/12/21
    CI/CDなどにおけるサプライチェーンセキュリティについて。 CI/CDパイプラインにおける脅威モデルと攻撃手法について
  • Accelerate your deploys with these 5 CircleCI optimizations

    At Transcend, we build, test, and deploy all of our application code through CircleCI. In order to maintain a quick developer feedback loop, we recently optimized our pipeline for performance. We were able to reduce our build, test, and deploy cycle time from 22 minutes down to just 8 minutes without removing any generative or integration tests. Further, we were able to drop unit testing times on

    Accelerate your deploys with these 5 CircleCI optimizations
    efcl
    efcl 2022/04/23
    Circle CIのパフォーマンス改善
  • GitHub Actions のデバッグをローカルで行う

    概要 GitHub Actions で GitHub ホストランナーを使用する場合、パブリックポジトリは無料ですがプライベートリポジトリは従量課金(無料枠あり)です。 ワークフローを編集する際にデバッグしていると結構な時間を消費してしまいます。 そこでデバッグ時は GitHub ホストランナーを使わずに無料で実行する方法を 3 種類紹介します。 nektos/act 言わずと知れたローカル実行ツールです。 すべてを再現することはできませんがコミットを増やさずにデバッグができます。 注意点 ubuntu-* のみサポート ソフトウェアは指定する Docker イメージ依存、デフォルトのイメージだと色々足りないので -P で指定 secrets.GITHUB_TOKEN が未定義なので Personal Access Token を発行し設定が必要 サービスコンテナ services が使えな

    GitHub Actions のデバッグをローカルで行う
    efcl
    efcl 2021/06/07
    GitHub Actionsのローカルデバッグ方法について
  • CircleCI 2.0でのスローテスト(テスト遅い)問題対処法を思いつくだけ書き出す - Qiita

    まえおき スローテストの解消に関して、昨今のCIサービスを考慮した観点で自分なりの手法をまとめてみる。 CIで出来そうなことは可能な限り網羅したつもりだが、他にもあったらコメントか編集リクエストでご指摘いただきたい。 とりあつかうこと・とりあつかわないこと CircleCI 2.0 を前提とする。 1.0はもうすぐ無くなるので対象外 他のCIサービスは今回対象としてないが、一部似たような機能があるかもしれない。 テストフレームワーク固有の話はなるべく排除している サンプルコードがnodeだったりrubyだったりで統一取れてないのはご了承いただきたい。 dockerモードを前提とする。machine: trueでの実行は検証していない 検証してないだけなので、もしかしたら動くものもあるかもしれない CIではなくCD(継続デリバリー)に特化した話は除外する 転用できる部分はあるものの、あまりフ

    CircleCI 2.0でのスローテスト(テスト遅い)問題対処法を思いつくだけ書き出す - Qiita
    efcl
    efcl 2018/07/19
    Circle CIのパイプラインの最適化などについて
  • 1