- 投稿日:2020-01-10T23:51:19+09:00
git blame の表示範囲を絞り込む
- 投稿日:2020-01-10T22:09:01+09:00
Ruby on Railsのアプリケーションをgit cloneする
はじめに
学生エンジニアの覚え書きです。参考になれば幸いです。
使用しているPCはMacを使用しているのでWindowsの方は注意してください。まずはGitHubからcloneをする
クローンするアプリケーションを置きたいディレクトリに移動したあと
$ git clone https://github.com/example/test.gitURLにはクローンしたいリポジトリのURLを入れてください
bundle installをする
クローンしたアプリケーションで使用するgemをインストールします。
$ bundle installこれでうまくいくはずが
An error occurred while installing mysql2 (0.5.3), and Bundler cannot continue. Make sure that `gem install mysql2 -v '0.5.3' --source 'https://rubygems.org/'` succeeds before bundling. In Gemfile: mysql2エラーが出ました
mysql2のgemfileがインストールできない様子ググって見ると、こちらの記事を発見し解決できました。
【Rails】MySQL2がbundle installできない時の対応方法$ bundle config --local build.mysql2 "--with-cppflags=-I/usr/local/opt/openssl/include" $ bundle config --local build.mysql2 "--with-ldflags=-L/usr/local/opt/openssl/lib"このコマンドを打ったあと
$ bundle installすると、うまくインストールできました。
Bundle complete! 22 Gemfile dependencies, 97 gems now installed. Use `bundle info [gemname]` to see where a bundled gem is installed.データベースの作成
ここからはデータベースを作成していきます。
$ rails db:create $ rails db:migrateこれでデータベースは作成できました。
アプリケーションの起動
ここまで来たら最後に
$ rails sをして起動すれば完了です。
最後に
今回はGitHubからcloneしたアプリケーションをローカル環境で動かすことをしました。
起動したあとも正常に動作しない点はあると思うので動作確認は怠らないようにしてください。注意点としてcloneした際に.gitignoreに指定されているフォルダ、ファイルはcloneされないのでAPIキーなどを.envなどのファイルに書いている方は作成してください。
- 投稿日:2020-01-10T15:35:02+09:00
Jenkinsを使わずにGitLabとSonarQubeを連携してみた
背景
ソースコードをcommit/pushした際の自動レビューと、コード品質の可視化のためにSonarQubeを導入することになった。
既にソースコードはGitLabで管理しており、GitLab-CIを使ってビルドやテスト、デプロイの自動化まで実装済み。今さら感はあるが、GitLabとSonarQubeの連携方法について調べてみた。
Jenkinsは必要か?
調べていくと、どの事例もJenkinsを間に挟んでGitLabとSonarQubeを連携させている。
図にするとこんな感じ。正確には、SonarQube側には
sonar-scannerという登場人物もいて、実際の解析を行っているのは彼ですが、ココでは細かいことは割愛。もともとJenkinsを導入済みのプロジェクトであれば、この構成でも良いと思うが、未導入の場合は無駄な構成のように感じた。
実際、私のプロジェクトもJenkinsは導入していなかった。
SonarQubeに加えてJenkinsが必要なため構築に2倍の労力がかかるし、SonarQubeのためだけにJenkinsを動かしておくのも経済的とは思えない。一方で、Jenkinsを導入したほうが良いケースもありそう。
Jenkinsのジョブのトリガは、きめ細かに設定することができるので、「日次や週次で定期的に実行させたい」といったケースなどであれば、Jenkinsの導入が有効かもしれない。ただ、私のプロジェクトでは、GitLabへのコードのPushやマージリクエストのタイミングで実行できれば十分だったので、やはり
私のプロジェクトではJenkinsはいらないという結論に至った。ということで、次の図のような、よりシンプルな構成で導入を試みることにした。
環境
- CentOS 7.5.1804
- GitLab CE 11.11.3
- gitlab-runner v12.6.0
- SonarQube Community Edition Version 7.6 (build 21501)
SonarQubeのインストール
公式が提供しているDockerイメージを使用する。
今回は、簡単に構築するために、公式のdocker-composeサンプルを活用する。公式のdocker-composeサンプルをダウンロード
mkdir SonarQube cd ./SonarQube curl https://raw.githubusercontent.com/SonarSource/docker-sonarqube/master/recipes/docker-compose-postgres-example.yml -o docker-compose.ymldocker-compose.ymlをカスタマイズ
以下のように、
docker-compose.ymlをカスタマイズする。docker-compose.ymlversion: "2" services: sonarqube: # コンテナ名を明示的に指定(必須) container_name: sonarqube-core # SonarQubeのバージョンを"7.6-community"に指定(必須) image: sonarqube:7.6-community ports: - "9000:9000" networks: - sonarnet environment: - sonar.jdbc.url=jdbc:postgresql://db:5432/sonar volumes: - sonarqube_conf:/opt/sonarqube/conf - sonarqube_data:/opt/sonarqube/data - sonarqube_extensions:/opt/sonarqube/extensions # マシンやdockerデーモンの再起動でコンテナが立ち上がるように(お好みで) restart: always db: # コンテナ名を明示的に指定(推奨) container_name: sonarqube-postgres # postgresのバージョンも固定化(お好みで) image: postgres:12.1 networks: - sonarnet environment: - POSTGRES_USER=sonar - POSTGRES_PASSWORD=sonar volumes: - postgresql:/var/lib/postgresql # This needs explicit mapping due to https://github.com/docker-library/postgres/blob/4e48e3228a30763913ece952c611e5e9b95c8759/Dockerfile.template#L52 - postgresql_data:/var/lib/postgresql/data # マシンやdockerデーモンの再起動でコンテナが立ち上がるように(お好みで) restart: always networks: sonarnet: driver: bridge volumes: sonarqube_conf: sonarqube_data: sonarqube_extensions: postgresql: postgresql_data:SonarQubeを起動
# 仮想メモリの上限値を変更(省略するとSonarQubeが無限に再起動を繰り返す) sudo sysctl -w vm.max_map_count=262144 # 起動 docker-compose upSonarQubeのダッシュボードにアクセス
ブラウザで下記のURLにアクセス。
ユーザ名とパスワードはadminでログインできる。http://{your_IP_address}:9000/SonarQubeへのプラグインのインストール
sonar-gitlab-plugin
GitLabと連携するためのプラグイン。
ネット情報では、SonarQubeのGUI上から検索してインストールできるようだったが、私の環境では検索してもヒットせず。
このため、手作業でインストールを実施。なお、
sonar-gitlab-pluginがサポートするSonarQubeのバージョンは7.6まで。
docker-compose.ymlでバージョンを指定したのはこのため。# GitHubからパッケージをダウンロード curl https://github.com/gabrie-allaigre/sonar-gitlab-plugin/releases/download/4.1.0-SNAPSHOT/sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar -o sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar # パッケージをsonarqube-coreコンテナにコピー # ※あらかじめdocker-compose.ymlでコンテナ名をつけているので、コンテナの指定が楽にできる docker cp sonar-gitlab-plugin-4.1.0-SNAPSHOT.jar sonarqube-core:/opt/sonarqube/extensions/pluginsSonarQubeのダッシュボードにログインし、
Administration>System>Restart Serverで、SonarQubeを再起動する。再起動後、
Administration>Marketplace>Installedで、GitLabが表示されていればOK。その他のプラグイン
主要な言語用のプラグインなどは、プリインストールされている。
インストール済みのプラグインの確認は、Administration>Marketplace>Installedで確認可能。もし不足している場合は
Allタブで検索して追加する。
SonarQube上で検索してヒットしない場合は、GoogleやGitHubなどで検索し、sonar-gitlab-pluginと同様の手順で手動インストールする。私のプロジェクトの場合、JavaScriptの静的解析のプロファイルに
ESLintを使用したかったので、sonar-eslint-pluginを追加でインストール。
こちらも、SonarQubeのGUI上ではインストールできなかったので、手動でインストールした。SonarQubeの設定
Administration > Configuration > General Settings > GitLab
最低限、以下の項目を設定する。
その他は、必要であれば、個別の環境に合わせて設定する。
項目 設定値 備考 GitLab url {your_GitLab_URL} GitLab User Token {your_GitLab_User_Token} 後述の手順で取得したトークン Quality Profiles
各言語の静的解析に使用するプロファイルを選択する。
標準ではSonar wayという、SonarQube推奨のプロファイルが選択されている。特にこだわりがない場合や、プロジェクトで決まっているものがなければ、デフォルトのままでも問題ない。
もし、ルールを変更する場合は、使いたいプロファイル横の歯車アイコンからSet as Defaultをクリック。私の場合は、前述の通りJavaScriptのDefaultプロファイルをESLintに変更した。
Projects
右上の
+アイコンから、新規プロジェクトを作成し、以下の情報を設定。
項目 設定値 備考 Project key {your_repository_name} Display name {your_repository_name}
Analyze your project画面に遷移するので、Generateをクリック。
表示されるトークンをメモしておく。さらに、作成されたプロジェクトを開き、
Administration>General Settings>GitLab>GitLab Project idに、GitLab上の解析対象プロジェクトのIDを登録しておく。GitLabの設定
gitlab-runnerのインストール
GitLab-CIを実行するためのgitlab-runnerをインストールする。
既にDocker executorのgitlab-runnerが存在する場合、この手順は省略可。# docker版の`gitlab-runner`を起動 docker run -d \ --name gitlab-runner-docker \ --restart always \ -v /srv/gitlab-runner-docker/config:/etc/gitlab-runner \ -v /var/run/docker.sock:/var/run/docker.sock \ gitlab/gitlab-runner:v12.6.0 # GitLabにrunnerを登録 docker exec gitlab-runner-docker gitlab-runner register \ --non-interactive \ --url {your_gitlab_url} \ --registration-token {your_gitlab_runner_token} \ --name "gitlab-runner-docker" \ --tag-list "autotest-server,docker" \ --executor "docker" \ --docker-image "alpine:latest"SonarQubeが使用するBOTアカウントを設定
SonarQubeが、静的解析結果をコミットやマージリクエストに対してコメントするためのアカウントを作成する。
BOTアカウントを作成
項目 設定値 備考 Name SonarQube 他の名前でも可。投稿に表示されるので、SonarQubeからの投稿であることが分かりやすいように命名する。 Username SonarQube 他の名前でも可。 任意のメールアドレス Avatar SonarQubeのアイコンなどを設定するとわかりやすい BOTアカウントに権限を付与
作成したBOTアカウントに、対象プロジェクトへの
Developer権限を付与する。BOTアカウントのトークンを取得
作成したBOTアカウントでログインし、
Settings>Access Tokensで新規のアクセストークンを発行する。
項目 設定値 備考 Name SonarQube 任意の名前で可。 Expires at (空欄) Scopes api 発行したトークンは、SonarQubeの
Administration>Configuration>General Settings>GitLab>GitLab User Tokenに登録する。SonarQubeのトークンをgitlab-runner用の環境変数に登録
解析対象のプロジェクトの、
Settings>CI / CD>VariablesにSonarQubeのトークンを追加する。
項目 設定値 備考 Type Variable Key SONARQUBE_TOKEN Value {your_sonarqube_token} 前述の手順で取得したトークン
sonar-project.propertiesの作成解析対象のプロジェクト直下に、下記のファイルを作成する。
設定値は、各環境に合わせて変更が必要。sonar-project.properties# プロジェクト情報(SonarQubeで設定した内容) sonar.projectKey={your_repository_name} sonar.projectName={your_repository_name} # プロジェクトのバージョン(SonarQubeのGUI上で解析結果をバージョンごとに管理可能) sonar.projectVersion=1.0 # ソースコードのパス sonar.sources=src # ソースコードから除外する条件 sonar.exclusions=**/*.spec.js # テストコードのパス sonar.tests=src,config # テストコードに加える条件 sonar.test.inclusions=**/*.spec.js # 言語を指定しない場合、自動で言語認識をしてくれる。 # 自動認識の場合は、複数言語の認識にも対応。(Javascript + CSSなど) # sonar.language=js # カバレッジレポートのパス sonar.javascript.lcov.reportPaths=coverage/lcov.info # エンコーディング sonar.sourceEncoding=UTF-8
.gitlab-ci.ymlの作成GitLab-CIが実行する処理を定義する。
sonar-scannerという、SonarQubeの解析処理を実行するプログラムが実施されるように定義していく。なお、sonar-scannerについては公式のDockerイメージを使用する。
インストールして使うこともできるが、不用意に環境を汚したくないし、導入が簡単なDocker版を採用。
公式のDockerイメージは、2020/01/10時点で未だにBeta版だが、今回の用途では何ら問題なく使用することができた。.gitlab-ci.ymlstages: - analysis analysis: stage: analysis image: name: sonarsource/sonar-scanner-cli:4.2 entrypoint: [""] allow_failure: true variables: SONAR_HOST_URL: http://{your_SonarQube_IP}:9000 SONAR_TOKEN: ${SONARQUBE_TOKEN} SONAR_PROJECT_BASE_DIR: ${CI_PROJECT_DIR} script: - |- sonar-scanner \ -Dsonar.gitlab.project_id=$CI_PROJECT_ID \ -Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME \ -Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA tags: - docker公式のDockerイメージは、
docker runコマンドで使用されることを前提に作成されており、渡せる環境変数やオプションが限られている。
今回は、GitLabのプロジェクトID、ブランチ名、コミットハッシュを渡したかったため、entrypointを上書きしてコンテナ内でsonar-scannerを直接実行するようにしている。いよいよ実行
ここまで設定した状態で、GitLabにコードの変更がPushされると、
gitlab-runnerでsonar-scannerが実行され、静的解析の結果がSonarQubeに登録されるとともに、GitLabのコミットやマージリクエストに対するコメントとしても投稿される。各登場人物の仕事を図に表すと、こんな感じ。
もし、静的解析の結果をSonarQubeのダッシュボードに登録したくない場合は、
-Dsonar.analysis.mode=previewというオプションを追加すると良い。その他のTips
SonarQubeBOTの投稿コメントに、SonarQubeダッシュボードへのリンクを追加するSonarQube標準の設定では、GitLabに投稿されるコメントにSonarQubeダッシュボードへのリンクは含まれない。
しかし、静的解析結果を読んだら、グラフィカルなダッシュボードで詳細を見たくなるはず。以下の設定をすることで、SonarQubeダッシュボードへのリンクを追加することができる。
Administration>Configuration>General Settings>GitLab>Global templateYou can check the details on the [SonarQube dashboard](${sonarUrl}). (Login username and password is `admin`.) The summary of the analysis results is as follows. --- <!-- ここに、以下のURLからコピーしたマークダウンを貼り付ける --> <!-- https://github.com/gabrie-allaigre/sonar-gitlab-plugin/blob/master/templates/global/default.md -->
Administration>Configuration>General Settings>GitLab>Inline templateYou can check the details on the [SonarQube dashboard](${sonarUrl}). (Login username and password is `admin`.) The summary of the analysis results is as follows. --- <!-- ここに、以下のURLからコピーしたマークダウンを貼り付ける --> <!-- https://github.com/gabrie-allaigre/sonar-gitlab-plugin/blob/master/templates/inline/default.md -->
- 投稿日:2020-01-10T14:51:05+09:00
RStudioでGitが正常に連携しないときの解決法
趣旨
大学院の友人に「RStudioとGitHub繋げたらすっげー便利になったからYOUもやっちゃいなよ」と言われた翌日、ポチポチPCを弄りながら導入を試みたところ、こんな状態に。
あっれー。
ということで、色々変えること2時間、だいぶ遠いところに原因がありましたとさ。ところで、「解決方法だけ知りたいんだよ!」という
せっかちさん時間を大切に使いたい方は、今すぐ解決策2へGO。細かいことはさておき。
Gitにも文字コードにも全く明るくないが、これに限った話ではなく、とにかくSHIFT-JISはあちこちでエラーを起こしまくる問題児。
Gitでも、SHIFT-JISを使おうとすると、それなりに手間がかかるようだ。(参考)Git / SourceTree で、Shift JIS ファイルの差分を文字化けなく表示する- Qiita
この
諸悪の根源SHIFT-JISが、GitとRStudioの連携を阻んでいる、かもしれない。
この時点ではまだ推測。WindowsのデフォがSHIFT-JISなので。
そろそろSHIFT-JISなんて廃止してほしいと思うのだが、RStudioとGit (両方ともUTF-8のほうが相性が良い。らしい。) の架け橋であるWindowsそれ自体がSHIFT-JIS (正確にはCP932) がデフォみたいなので、どうも相性がわるい。
で、色々実験しているうちに分かったのは、フォルダやファイルのパスに日本語が含まれていると、連携ができないということ。やってんなーお前。
実際、パスが英数字のみの場合は、普通に連携できた。解決策1 (強硬篇) : システム・ロケールをUTF-8にする
というわけで、
コントロールパネル > 時計と地域 > 地域 > 管理と開きーの。
システムロケールの変更をクリックして、
ベータ: ワールドワイド言語サポートでUTF-8を使用をチェック。すぐPCの再起動が求めらます。そして改めてRStudioを起動すると...
\パンパカパーンッ/
めでたしめでたし。副作用(悪い意味で)
ただし、この方法はあんまりオススメできません。
その1
この状態のままプロジェクトを保存しようとすると、RStudioがクラッシュします。ホントです。
なので、プロジェクトは保存しないこと前提に使う分にはまぁ・・・という。本末転倒感、半端ない。その2
他のプログラムが文字化けすることがあります。
なので、一時的でいいからどうしても連携させたい場合「だけ」ならアリですが...解決策2 (妥協篇) : ファイル名やフォルダ名に日本語を使わない。
はい、これに尽きます。システムの文字コードが何であろうとエラーにならないです。
そして、ローカル・スケールも変更する必要もないので、他のプログラムへの影響はゼロ!
まあしょうがないよね!僕と一緒に妥協しましょう。おわりに
文字コードは大事。
おしまい。
参考
Git自体の導入や、RStudioの連携手順等は、こちらが大変参考になりました。
RStudioではじめるGitによるバージョン管理 - Qiita
IT苦手な人のためのWindows+gitでRStudioによるバージョン管理入門 - Analyze IT.
- 投稿日:2020-01-10T14:19:48+09:00
Initial commitに後続のcommitを含めたい
Initial commitに後続のcommitを含めたかったので、
git rebase -i HEAD^^^したところ、
fatal: Needed a single revision invalid upstream 'HEAD^^^'と表示されてできない。
調べてみると
git rebase -i --rootでInitial commitを含めたrebaseができるらしい。
実際にやってみるといつものrebase画面にInitialCommitが表示されたので、
普段のrebaseと同様にsquashすることで後続のCommitを消してInitalCommitに含めることができた。
- 投稿日:2020-01-10T12:14:17+09:00
git操作を間違えてremoteブランチを全部削除してしまったと思ったら、何とか大丈夫だった話
起きたオペレーションミス
リモートブランチを消すために
git push oirign :<消したかったブランチ>をやろうとしたところ、ブランチ名をペーストする前にエンターを押してしまい、
git push oirign :を実行してしまった。
ブランチ名を指定しなかったということは、全てのブランチが消されてしまうのでは?!と非常に焦った。実行して表示されたもの
$ git push origin : To git@hoge.com:fuga/fuga.git ! [rejected] develop -> develop (non-fast-forward) ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to 'git@hoge.com:fuga/fuga.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and integrate the remote changes hint: (e.g. 'git pull ...') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details.
failed to push some refsとあるということは、いくつかのブランチに対してはpushがされたということか?!
non-fast-forwardでローカルのブランチが古かったものは何もされていないけど、最新だったブランチは削除されてしまったの?!後から冷静に読めば
最新でないブランチだったからpush出来なかったと書いてあるだけなのだけど、
git push origin :<ブランチ名>でブランチを削除出来るのだから、pushという操作にブランチ削除も含まれるのではと思い焦っていた。
急いでremoteのブランチ一覧を確認
元々いくつbranchがあったかは分からないけど、どうやらブランチは残っていそう。
でも何が起きたか分からないと不安で仕方ない。git push origin : の挙動を落ち着いて調べてみる
git pushドキュメントの例に
git push origin :があったの読んでみた。
https://git-scm.com/docs/git-push#Documentation/git-push.txt-codegitpushorigincodePush "matching" branches to origin. See <refspec> in the OPTIONS section above for a description of "matching" branches.
"matching" branchesをpushするらしい。
"matching" branchesが何を示すのか確認してみた。:は"matching branch"を表す
https://git-scm.com/docs/git-push#OPTIONS
に説明があった。The special refspec : (or +: to allow non-fast-forward updates) directs Git to push "matching" branches: for every branch that exists on the local side, the remote side is updated if a branch of the same name already exists on the remote side.
"matching" branchesは
- ローカルに存在するブランチで
- リモートに同名のブランチがある
をブランチを示す。
今回だとmasterやdevelop、開発していたfeatureブランチなどがローカルにあったので、
今回間違って打ったgit push origin :は、
git push origin master git push origin develop git push origin feature/xxxx git push origin feature/yyyy git push origin <その他ローカルにあってリモートにもあったブランチ名> ...を実行したのと同義だった。
masterやdevelopはローカルを最新化していなかったので、! [rejected] develop -> develop (non-fast-forward) ! [rejected] master -> master (non-fast-forward)などと表示されたということだった。
開発で使うコマンドを覚えて置くだけだと、ミスした時とても焦る
普段開発で使うコマンドを調べてメモしたり覚えておけば、普段git操作で困ることはない。
しかしコマンドを間違えてしまった場合に、:など意味を知らないとテンパってしまう。
時折ドキュメントを見返したり、git関連の書籍を読んでおくは大事だと改めて思った。git参考書籍
GitHub実践入門
新卒エンジニア向け課題図書だったけども、改めて読み直すつもり。
- 投稿日:2020-01-10T01:35:06+09:00
git initの取り消し方
git initで新規リポジトリを初期化するディレクトリを間違えてしまって、git initを取り消せないかと思って調べてみました。解決するには当たり前ですがバージョン管理をしている
.gitディレクトリを削除すればOKです。# git initをしたディレクトリで行う $ rm -rf .git上記のコマンドで見事
git initが無かったことになりました!
簡単でしたね!
- 投稿日:2020-01-10T00:24:24+09:00
プルリクをrevert(打ち消す)してみた!
最近の勉強で学んだ事を、ノート代わりにまとめていきます。
主に自分の学習の流れを振り返りで残す形なので色々、省いてます。
Webエンジニアの諸先輩方からアドバイスやご指摘を頂けたらありがたいです!初めてのGit revert
先輩エンジニアから「このプルリクrevertするのお願い〜」と言われ
あれ、そういえばrevertってどうするんだっけと思い実際に行ったフローをまとめてみました!
Pull Request を打ち消す
Github公式が分かりやすく説明してくれております。
Pull Request は上流ブランチへのマージ後に元に戻すことができます。
GitHub で Pull Request を打ち消すと、マージされた元の Pull Request からマージ コミットを 1 回元に戻した、新しい Pull Request が作成されます。このHelpの手順に従いPull Request の下部周辺で、[Revert] をクリックします。
ここでPull Requestが打ち消す為のPull Requestを作成しそれをマージしたら見事、プルリクを打ち消すことができました!
簡単簡単!
参考記事







