- 投稿日:2019-12-15T23:56:14+09:00
jenkinsとgitつなげる
https://open-groove.net/jenkins/tomcat-maven-git/
ls -l /usr/local/jenkins/plugins 以下に
・git.hpi
・git-client.hpi
・scm-api.hpiがあるのを確認
プロジェクト 設定
ソースコードの管理
✓ Git
・Repository URL
http://192.168.10.xx:8080/gitbucket/git/root/test.git
(gitbucketで設定されたURL)
・Credentials なし
以下デフォルト手動で実行
## 以下動かない?
/root/test/.git/hooks
ができるのでvi post-receive
!/bin/bash
curl -X POST http://192.168.10.xx:8090/jobs/app-test-job/builds
参考
https://ics.media/entry/3283
JenkinsでCI環境構築チュートリアル ~GitHubからWebサーバーへのデプロイ~
- 投稿日:2019-12-15T22:37:09+09:00
Git for Windowsでautocrlfの設定を間違えちゃった時の対応
この記事は ZOZOテクノロジーズ #5 Advent Calendar 2019 16日目の記事です。
昨日は @meganekids さんによる「エンジニアとプロジェクトマネージャー向けのAdobe XD勉強会で意識した4つのこと」でした。
別職種の人とのコミュニケーションを円滑にするための知識の土台作りはとても大事だと思うので、アフターケアを含め取り組む姿勢がとても素敵だと思いました。本記事はWindowsではまりがちなgitの改行コード自動変換機能のお話です。
背景
私が所属しているMA(マーケティングオートメーション)チームではWindows ServerとLinuxのサーバを両方使って開発をしています。
Windowsでしか動かないVBScriptやLinuxでよく使うシェルスクリプトを両方扱っており、文字コードや改行コードに配慮しないと問題が発生してしまう、とてもエキサイティングな職場です。
(文字コードについてはこちらの記事に書いてますので興味があればどうぞ > Qiitaの記事)改行コードについてはgitにautocrlfという自動変換してくれる機能があり、上手く使えば便利です。
しかし、この機能がONになっていると、commitログとファイルシステムが認識している実態に乖離が生じてデプロイ結果が期待と異なるケースがありえます。Git for Windowsは親切なことに、インストール時にautocrlfの設定を任意で選択することができます。
一番上の設定にすると、
autocrlf=true
という設定になり、改行コードの自動変換が有効になります。
ここで選択できるのは良いのですが、その後悲しいことにGUIでは設定変更ができません(やり方あれば教えて欲しい)。間違えてautocrlfがtrueになってしまったら、gitのコマンドを駆使してゴニョゴニョする必要があったので、そのときの対処法をまとめようと思います。操作自体は簡単なので、周辺知識の整理的な意味合いが強いです。
環境
この記事はWindows10を使っていてかつ、gitの環境をGit for Windowsでインストールした環境を想定しています。
Git for Windowsのバージョンによる差異は後ほど記述しますが
v2.19(私が最初インストールしたもの)とv2.24(記事作成時最新)が登場します。autocrlf
改行コードは利用するOSによって標準で利用するものが異なります。
特にWindowsではCRLF, MacではLFが標準で利用されます。サーバをLinuxOS上で動かしていれば、何かしらのシェルスクリプトを利用することはよくあると思いますが、
シェルスクリプトの改行コードがCRLFになっていると困るため、gitの設定にautocrlfという改行コードを自動変換する機能があります。これはgitでcommitした時とcheckoutした時に自動的に改行コードを変換する仕組みです。
要は作業中の改行コードとcommitログとして記録される改行コードをシステム的に固定する機能のことです。基本的にWindows Serverを使っているような環境(CRLFが必要な環境)で開発しているのであれば、autocrlfはfalseにすべきだと思います。
autocrlf=trueは最終的にgitに記録する改行コードをLFに固定化する時に使う設定なので、LF以外を駆逐するときに利用しましょう。下記のgitのドキュメントのcore.autocrlfの項目に記載があるので、そちらを参照してください。
https://git-scm.com/book/ja/v2/Git-%E3%81%AE%E3%82%AB%E3%82%B9%E3%82%BF%E3%83%9E%E3%82%A4%E3%82%BA-Git-%E3%81%AE%E8%A8%AD%E5%AE%9Agitの設定は
git config
というコマンドを使って変更が可能ですが、その際環境が3つある点に注意が必要です。
- system: gitのシステム全体に適用される設定
- global: ホームディレクトリ直下の設定ファイルを見るため、ユーザ単位で全適用される設定
- local: gitで管理しているレポジトリの.git配下の設定ファイルを見る、レポジトリ単位の設定
それぞれ --system, --global, --local とオプションを指定して利用できます。
現在gitのconfigがどのファイルによって何に設定されているかは下記のコマンドでみるとわかりやすいです。
git config --show-origin core.autocrlf
--show-origin
をつけることで、どのファイルによる設定されているかがわかります。ここが重要なポイントですが、gitの設定ファイルは
local > global > systemの順で優先されます。個別に設定した内容は優先して適用されるようです。
git config --helpで出力されるドキュメントの中には下記のように書いてます。優先度については特に記述はないですが、一応載せておきます。
When reading, the values are read from the system, global and repository local configuration files by default, and options --system, --global, --local and --file <filename> can be used to tell the command to read from only that location (see the section called "FILES").Git for Windowsによる自動設定
ここで実際にインストール時の設定がどのように反映されるのか見て行きます。
Git for Windowsはインストール時にautocrlfの設定を選ぶことができます。
この時しっかり理解して設定していればきっと問題は起きないでしょう。ここで一番上の選択肢を選ぶと、autocrlf=trueな環境のgitが完成します。
設定内容を確認します。
インストール直後はこうなります。
v2.24$ git config --show-origin core.autocrlf file:C:/Program Files/Git/etc/gitconfig truev2.19$ git config --show-origin core.autocrlf file:"C:\\ProgramData/Git/config" trueバージョンによって設定ファイルは異なりますが、このような設定になります。
Git for windowsのリリースノートによると v2.23へのアップデートよって設定ファイルの配置場所が変わったようです。
Note! As a consequence of making git config --system work as expected, the location of the system config is now C:\Program Files\Git\etc\gitconfig (no longer split between C:\Program Files\Git\mingw64\etc\gitconfig and C:\ProgramData\Git\config), and likewise the location of the system gitattributes is now C:\Program Files\Git\etc\gitattributes (no longer C:\Program Files\Git\mingw64\etc\gitattributes). Any manual modifications to C:\ProgramData\Git\config need to be ported manually.設定の変更方法
環境毎に説明します。
local
とにかくこのレポジトリだけ対応したい。ということであれば下記の方法でlocalの設定を更新します。
git config --local core.autocrlf falseすると、設定値が下記のようのなります
$ git config --show-origin core.autocrlf file:.git/config falseこれにて特定レポジトリに対する設定は完了です。
一番手軽で、影響範囲が少ないです。global
基本的にautocrlfがfalseでよければこちらの方がまだ良いでしょう。
git config --global core.autocrlf false--localに設定されていなければ、下記の表示になります。
$ git config --show-origin core.autocrlf file:C:/Users/{username}/.gitconfig falsesystem
根本的に変えたいならこちらの設定を変えましょう。こっちを変えたほうが安心です。
しかし、こちらは権限の問題があるので、Git Bashを「管理者として実行」で起動させてからコマンドを実行する必要があります。git config --system core.autocrlf falseその結果、v2.19ではなぜか別ファイルが作られます。なんでやねん。
$ git config --show-origin core.autocrlf file:C:/Program Files/Git/mingw64/etc/gitconfig false
C:\\ProgramData/Git/config
には true で設定されていますが、C:/Program Files/Git/mingw64/etc/gitconfig
のfalseが優先されるようです。こうなるなら
C:\\ProgramData/Git/config
を手で書き換えた方が気分がいいですね。ただ、v2.24では同じファイルが上書きされたので、新しいの使った方が綺麗に修正できます。
Git for Windowsが古い場合はv2.23以降のバージョンにアップデートして、その時autocrlfをfalseにする設定でインストールするが綺麗かもしれません。
再インストール
一番下のラジオボタンを選べば、autocrlf=falseの状態でsystemのconfigが作られます。
最後に
今回もWindows環境と向き合う記事でした。バージョンの違いによる挙動の違いは結構混乱の元だと思うので、その辺を整理できてよかったです。
普段Macを使っているからという理由で億劫になりがちな問題ですが、CRLFな改行コードが必要な世界もあるということを理解しておくことは、開発をする上で大事なことだと思うのでこれからも立ち向かっていきたいですね。明日は @satto_sann による記事なので、そちらもぜひご覧ください〜
- 投稿日:2019-12-15T18:58:50+09:00
【SourceTree】SourceTreeでBranchしてPushができなかった為、Git Bashで対応した
環境
SourceTree
Windows 10
Git BashSourceTreeにてBranchを追加してPush
The リモートブランチ '' (ローカルブランチ = 'hoge/fuga') is invalid. Ref names must follow git ref-format rules: https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html エラー終了しました。エラーの内容は上記をご覧ください。→リモートブランチが空白になっている(未作成だから?)
↓
Git Bashで単純なgit push実行
$ git push fatal: The current branch hoge/fuga has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin hoge/fuga→upstreamでないため実行コマンドを提示された
↓
--set-upstreamを付加してコマンド実行
$ git push --set-upstream hoge/fuga master fatal: 'hoge/fuga' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.→だめでした...
↓
-u(追跡オプション)をつけてコマンド実行
$ git push -u origin hoge/fuga→push成功!
- 投稿日:2019-12-15T18:58:50+09:00
?【SourceTree】SourceTreeでBranchしてPushができなかった為、Git Bashで対応した
環境
SourceTree
Windows 10
Git BashSourceTreeにてBranchを追加してPush
The リモートブランチ '' (ローカルブランチ = 'hoge/fuga') is invalid. Ref names must follow git ref-format rules: https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html エラー終了しました。エラーの内容は上記をご覧ください。→✖リモートブランチが空白になっている(未作成だから?)
↓
Git Bashで単純なgit push実行
$ git push fatal: The current branch hoge/fuga has no upstream branch. To push the current branch and set the remote as upstream, use git push --set-upstream origin hoge/fuga→✖upstreamでないため実行コマンドを提示された
↓
--set-upstreamを付加してコマンド実行
$ git push --set-upstream hoge/fuga master fatal: 'hoge/fuga' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.→✖だめでした...
↓
-u(追跡オプション)をつけてコマンド実行
$ git push -u origin hoge/fuga→?push成功!
- 投稿日:2019-12-15T17:24:11+09:00
GitHubチートシート
gitでUntracked filesを削除する
マージにおいて片方のファイルをそのまま取り入れる
2つのブランチ間でコンフリクトしているファイル fileA.txt と fileB.txt があるとする
# fileA.txt を現在チェックアウトしているブランチ側の対応に合わせる場合 $ git checkout --ours fileA.txt $ git add fileA.txt # add を忘れずに # fileB.txt をマージさせたブランチ側に合わせる場合 $ git checkout --theirs fileB.txt $ git add fileB.txt $ git commithttps://qiita.com/shisho/items/c1075d394f1edf1a5928
git resetを取り消す
git addのを取り消す
# 全てのファイルを取り消し $ git reset HEAD # 特定のファイルのみ取り消し $ git reset HEAD file_name
- 投稿日:2019-12-15T14:24:52+09:00
git pullは使わない?
周りにあまりgit pullを使っている人がいなそうだったので、調べてみた
git pullを使って考慮すること
git pullをすると、簡単な操作でリモートのブランチの変更差分をローカルのブランチにマージしてくれる。そのため、中では複雑な操作が流れている。細かい挙動を把握することはとても大変
git pullを使わない場合
・git push アップロード
・git fetch ダウンロード
・git merge 統合git pullを意識しないことで、シンプルに頭の中で考えられる。
gitの操作について、細かく意識できる。なれてきてから、pullを使用する。
まとめ
理解しないで、つかうのは危険だと感じた。
僕は基本SourceTreeを使っていたが、変更差分をみるのをSourceTreeにして、コマンド操作になれるように変えて細かい挙動も意識していこうと思った。参考にさせていただいたサイト
- 投稿日:2019-12-15T12:11:44+09:00
パスワードを聞かれずにGitHubに接続する設定方法
概要
初めてGitHubにアカウントを作った人が、コマンドでリモートリポジトリにプッシュできることを確認するまでの手続きをメモします。
対象読者
- 複数のGitホスティングサービスを使いたい
- リモートリポジトリとのやりとりにパスワードを聞かれないようにしたい
- Gitの使い方はある程度わかる
- GitHubは初めて
想定環境
- Gitはインストール済み(まだの方はこちらから)
- ローカルPCはMac
手順
GitHub側で新規リポジトリ作成
Repository nameにリポジトリ名を記入し、Create Repositoryで新規作成
以下の画面に移るので、赤枠URLを覚えておく。
(特にSSHが選択されていることを確認。HTTPだと公開鍵登録したあとの通信がうまくいかない)
ローカルに鍵を生成
$ ssh-keygen -t rsa -f ~/.ssh/github -C "適当なコメント" Generating public/private rsa key pair. Enter passphrase (empty for no passphrase): (そのままEnterキーを押す) Enter same passphrase again: (そのままEnterキーを押す)【任意】秘密鍵の方をわかりやすくリネームしておく
$ mv ~/.ssh/github ~/.ssh/github.pem秘密鍵のパーミッション変更
$ chmod 600 ~/.ssh/github.pemGitの接続設定
接続情報を追記する。
- ここの設定で各Gitホスティングサービスの鍵情報を個別に設定することによって、プッシュ時に自動で接続情報を切り替えてくれるようになる。
- Hostは任意でいいかと思って適当なものを入れていたが、接続に失敗した。注意。
$ vim ~/.ssh/config Host github.com (※絶対これ) HostName github.com (※絶対これ) IdentityFile ~/.ssh/github.pem TCPKeepAlive yes IdentitiesOnly yes User git (※絶対これ) Port 22GitHubに公開鍵を登録する
ローカルの公開鍵を確認+クリップボードへコピー
(catコマンドででてきた長い文章を頭から全てコピーしておく。ターミナルでは折り返しで表現されているかもしれないが、実物は長いひとつながりの一文のデータ。コピー時に改行コードが混ざるとうまく繋がらないので注意。)$ cat ~/.ssh/github.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAB......GitHubに戻って、右上メニューからSettingsを選択
左メニューより「SSH and GPG keys」を選択し、右上緑色の「New SSH Key」を選択。
接続確認する。
ローカルにリポジトリを作成
$ mkdir ~/githubtest $ mkdir ~/githubtest/gittest/ $ cd ~/githubtest/gittest/ $ echo "Hello Git" >> test.md $ git initコミットし、リモートへ接続。
$ git add test.md $ git commit -m "initial commit" $ git remote add origin git@github.com:mu-editech/GitHubTestRepo.git $ git push -u origin masterGitHubへ戻って、以下のような画面がでれば接続成功。
おしまい。
参考文献
- 【Qiita】【GitHub超初心者入門】この前初めてGitHubを使い始めたエンジニア見習いが書くGitHubの使い方と実践~とりあえず一緒に動かしてみようぜ!~
- 【Qiita】gitとsshのconfigについて(備忘録)
- GitHub (または Bitbucket) への接続アカウントを切り替える
- 投稿日:2019-12-15T06:51:56+09:00
Jenkins Declarative pipelineでSlackにGitのコミットログも通知する
小ネタ。Groovy大好き。
Jenkinsfile内で以下のメソッドを書いておいて、
pipeline
ブロック内でtoSlack(channnel: "hoge-channnel", tokenCredentialId: "hoge-token")
とすれば使える。def toSlack(Map args) { def changeMsgs = [] currentBuild.changeSets.collect { it.items }.flatten().each { entry -> def commitDate = new Date(entry.timestamp).format("yyyy/MM/dd HH:mm") def author = entry.class.name == "hudson.plugins.git.GitChangeSet" ? "<mailto:${entry.authorEmail}|${entry.author.toString()}>" : entry.author.toString() changeMsgs << "・${commitDate}-> ${entry.msg} by ${author}" } slackSend( channel: args?.channel, tokenId: args?.tokenId, color: "good", message: changeMsgs.size() > 0 ? changeMsgs.join("\n") : "・なし" ) }これぐらいの行数のスクリプトだったり、他のジョブと共通化したかったりすると、毎回書くのはツラいので、実際はJenkins Shared Library化してます。
なので、
slackSend
のcolor
の部分もビルド結果を変換してたりします。