Gitlab は マージリクエストに対してそれがマージされた結果を元にパイプラインを実行できます。 Pipelines for Merged Results | GitLab 便利そうですけど、これは gitlab.com なら Silver 以上、セルフホスティングなら Premium 以上じゃないと使えないようなので、Gitlab CE でも似たようなことをやる方法。 要するにパイプラインの実行時にマージしてしまえばいいので次のような感じに。 image: gitコマンドが使えるイメージ stages: - build .merge_result: &merge_result > [ "${CI_MERGE_REQUEST_TARGET_BRANCH_NAME:-}" != "" ] && git checkout "origin/$CI_MERGE_REQUEST_TARGET_BR
どのクラウドでも使えるサーバレス「GitLab Serverless」をGitLabが発表。KubernetesとKnativeがベース GitLab ServerlessはKnativeをベースにKubernetes上で稼働するサーバレスプラットフォームです。GitLabがホスティングするのではなく、AWSやGoogle Cloud Platformなどどのクラウドに対してもデプロイし使えることが最大の特徴と言えるでしょう。 GitLabはマルチクラウドに対応したサーバレス管理ツールを提供するTriggerMeshと協力することで、デプロイ後の運用まで一貫してGitLabで管理できるとしています。 現在、AWS LambdaやGoogle Cloud Functions、Azure Functionsなど主要なクラウドは独自のサーバレスプラットフォームを提供しています。しかしそれぞれのク
Getting your merge request reviewed, approved, and merged Domain experts Reviewer roulette Approval guidelines CODEOWNERS approval Acceptance checklist Quality Performance, reliability, and availability Observability instrumentation Documentation Security Deployment Compliance The responsibility of the merge request author The responsibility of the reviewer The responsibility of the maintainer Dog
この記事はTECH PLAY女子部のアドベントカレンダー2017/12/4のエントリーです。 2016年6月に『最新のテクノロジーを使って、新しい音楽の体験を生み出し、「音楽を演奏する人」「音楽を聴く人」にとって、より幸せな世界をつくる』というミッションを胸に会社を２人で起業しました。 今は、弦楽器の練習をBowingVisionを自社開発していて、世にリリースするべく開発に励んでいます。 さて、弊社は2人しかいないのに、並行にいくつかプロジェクトが走り、すごい量のタスクを抱えてしまう時があります。 今、どっちが何をやっていて、どれが優先順位なんだっけ？そういうことに悩まされないために試行錯誤して編み出した、弊社で実践しているgitLabとtoggleを使ったタスク管理と情報共有についてお話したいと思います。 gitLabとtoggleを選んだ理由無料で使えることが最大の理由で、かつgit
Incapsulaのセキュリティ研究者であるDaniel Svartman氏は8月30日(米国時間)、「Discovering a Session Hijacking Vulnerability in GitLab｜Incapsula」において、GitLabにセッションハイジャック可能な脆弱性が存在していたと伝えた。同氏は5月18日の時点でGitLabに問題を報告しており、対処が行われるまで情報公開を控えていたとしている。記事では、GitLabに存在していたセッションハイジャックの脆弱性がどのようなものであったか、GitLabがどのような対処をしたかを伝えている。 GitLabとは、Gitベースのリポジトリ管理、問題追跡、コードレビューなどが行えるOSS。 今回発見されたセッションハイジャックは古くから存在している脆弱性の1つ。セッショントークンを窃取されると、ユーザーになりすましてさまざ
by @dekokun on 2013/07/31 09:30 Tagged as: Git. 会社などでの開発において、「Gitをよく知らない人にmasterブランチを破壊されるのが怖い」「初心者にはまずブランチの詳しい動きを勉強させないといけないなぁ…大変だ…」という文脈でそういっているのであれば、GITLABでも導入してmasterブランチへの書き込み権限を制限させ、pull request(GITLABでは「merge request」と言う)のワークフローでも使えばいいんじゃないですか。 pull requestのワークフローは「とにかくブランチを切ってそこに対してpushをし、質問したいときとかマージしてほしいときにWeb UIからpull requestをしてね」くらいで全く問題なく動くため、非常に簡単に、そして「変なマージをしづらい」という意味で危険なく使えますし。 「GI
以前 CentOS 6.4 用の GitLab 自動インストールスクリプトを作ったが、GitLab 6.0 も出たことなので、新たに Ubuntu 用のものも用意した。これを使えば、1ステップで Ubuntu Server 上に GitLab 環境を構築できる。 前提 このスクリプトは、クリーンインストールした直後の Ubuntu Server での利用を想定している。動作確認は、Ubuntu 公式の Ubuntu Server 12.10 amd64 の Vagrant イメージ (quantal-server-cloudimg-amd64-vagrant-disk1.box) を用いて行なっている。OS のバージョンはおそらく 12.10 以上でも動くはずだ。 使い方 基本的には Cent 用のもとの同じで、はじめにホスト名を設定する。 $ sudo hostname gitlab.e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
