https://testnight.connpass.com/event/311263/
この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと
(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
1.この記事の立ち位置#自分がいつも調べていること、忘れがちな Tips や小ネタを列挙していく。そのため、網羅性は重視しない。 というのも、なにか調べていていろいろ読み漁った挙げ句、1周回って行き着くところは GitHub Actions の公式ドキュメントであり、たとえば Workflow の書き方は以下のページをよく開いている。 Workflow syntax for GitHub Actions - GitHub Docs それでも、公式ドキュメントで参照したい箇所を引っ張るための用語を知るまでに苦労することが往々にあり、この記事が、公式ドキュメントで参照したい箇所を導くための助けとなればと思い、書いていく。 2.Step と Job と Workflowの違いアレコレ#2-1.Step と Job と Workflow の違いの一行まとめ#Step < Job < Workflo
はじめにMicrosoftは脆弱性の診断行為をセーフハーバーにより許可しています。 本記事は、そのセーフハーバーを遵守した上で発見/報告した脆弱性を解説したものであり、無許可の脆弱性診断行為を推奨する事を意図したものではありません。 Microsoftが運営/提供するサービスに脆弱性を発見した場合は、Microsoft Bug Bounty Programへ報告してください。 要約VSCodeのIssue管理機能に脆弱性が存在し、不適切な正規表現、認証の欠如、コマンドインジェクションを組み合わせることによりVSCodeのGitHubリポジトリに対する不正な書き込みが可能だった。 発見のきっかけ電車に乗っている際にふと思い立ってmicrosoft/vscodeを眺めていた所、CI用のスクリプトが別のリポジトリ(microsoft/vscode-github-triage-actions)にま
Github actionでvenv環境をキャッシュする¶これまで、PythonのプロジェクトでGithub Actionを使うとき、こんな感じで仮想環境ごとキャッシュしていました。 # 仮想環境を作成 - name: Create venv run: | python3 -m venv .venv # 仮想環境をキャッシュから復元 - name: Cache venv dependencies uses: actions/cache@v1 with: path: .venv key: venv-${{ runner.os }}-${{ hashFiles('requirements.txt') }} restore-keys: | ${{ runner.os }}-venv-
あらすじ ふだん無意識に読み飛ばしているが使おうと思ったときに出てこなかった YAML の anchor と alias を使うと色々 DRY に書ける DRYに書いた Anchor/Alias YAML では &name (Anchor) で名前をつけて *name (Alias) で参照することができる*1。 Example1: 重複排除 こんな感じの CircleCI 用の config.yml。 version: 2 jobs: bundle_npm_dependencies: docker: - image: circleci/node:8.7.0 steps: - checkout - restore_cache: # <= 1つめ keys: - key-name-{{ arch }}-{{ .Branch }}-{{ checksum "yarn.lock" }} - ke
tl;dr 変更したファイルにrubocopやjscsを実行して、pull requestに自動でコメントさせる方法。 コマンドをパイプでつないで、CIからsaddlerコマンドで書き込みする。 デモリポジトリに rubocop, travis ci, jscs, travis ci エラーになるpull requestしてみてね! saddlerの実行結果イメージ 一番目がjscs, 二番目がrubocop。 流れ diffのあるファイル名を取り出す $ git diff --name-only origin/master README.md bin/run-tests.sh lib/example/travis_ci.rb こんなdiffにrubocop や jscsを実行したい。 diffのあるファイル名を取り出す。 lint実行したいファイルだけに絞り込む $ git diff -
現在、家族アルバム みてねというアプリのAutoLayout対応を進めていて、弊チームでは以下の3つのルールを対応必須とすることにしてみました。 全てのStoryboard/Xibでuse AutoLayoutのチェックを有効にする 全てのStoryboard/Xibでuse SizeClassesのチェックを有効にする AutoLayoutのmisplacedは必ず解消した状態でコミットする AutoLayoutはとにかく仕様が複雑で開発するのが大変なので、少しでも楽にしていくために最低限機械的にチェックできるところを自動化しました。 #!/bin/bash ! find . -name '*.xib' -o -name '*.storyboard' | xargs grep misplaced 2>&1 > /dev/null && \ ! find . -name '*.xib' -
忙しい人のためのまとめ で指定するシェルスクリプトには #!/bin/bash -xe か #!/bin/sh -xe つけるべき 経緯 Jenkins周りで調べることがあってたまたま下記のエントリを発見 Jenkinsのシェルの実行について - Qiita シェルの途中でこけても処理が続行されるため run() { command=$1 echo "$command" eval $command # if error code returned, exit this script with error code RET=$? if [ $RET -ne 0 ]; then exit $RET fi } のようなラッパ経由でコマンド実行してたのですがそれが不要だったという俺的衝撃事実!!! *1 検証 test1.sh(-xe つけてないスクリプト) #!/bin/bash ls unkn
Jenkinsはオープンソースで開発されているCIツールである。 Jenkinsのインストール Red Hat Enterprise Linux及びCentOSでJenkinsをインストールする例を示す。 # wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo # rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key # yum install jenkins Jnekinsの起動 # service jenkins start Starting Jenkis [ OK ] プロキシの設定 プロキシを設定するには、[Jenkinsの管理] - [プラグインの管理] - [高度な設定]から設定する。 J
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く