'Git'에 해당하는 글 17건

Freestyle project

Tool/Jenkins 2017. 2. 13. 23:40

Jenkins 설치를 진행하여 Jenkins 웹UI에 접속할 수 있었다. 영어와 한글이 혼합되어 있는 이 모습이 썩 맘에 들진 않는다;

암튼 다음 할 일은 Pipeline 을 생성하고 설정하여 우리가 하려는 CI 기능을 동작시키는 것이다.

Pipeline 이란 것은 빌드나 테스트, 배포 등의 단계를 구성하는 하나의 프로젝트 정도로 봐도 될 것 같다.


Pipeline 을 정의하는 방법은 두가지가 있다.

- 웹UI 를 이용하는 방법

- Jenkinsfile 을 이용하는 방법


어느 것을 사용하던 동작은 동일하다.

웹UI를 따라서 선택하고 입력한 것이나, Jenkinsfile 에 DSL 코드로 작성하는 것이나 동일한 동작을 하게 할 수 있다.

SCM 을 이용하여 협업 등을 이유로 메뉴얼에서는 Jenkinsfile 의 사용을 추천하고 있다.


그러나...


나는 freestyle project 를 먼저 사용해 봤다.

단계별 어떤 옵션들이 있는지 정도는 알아야 Pipeline 을 작성할게 아닌가 ㅜ



* Jenkins 에게 원하는 목표

- Git 소스 체크아웃

- 소스 빌드(gradle)

- 빌드 파일 원격 서버로 업로드



기본 설정


1. 플러그인 설치

[Jenkins 관리] - [플러그인 관리]

- git plugin

- gradle plugin

- publish over ssh 


2. ssh 서버 설정

[Jenkins 관리] - [시스템 설정] 에서 배포할 타겟 서버를 구성한다. (굳이 ssh 를 이용할 필요가 없다면 ftp 플러그인을 받아 설정하면 된다.)

- hostname / username 과 [고급]에서 private Key 입력

- Test Configuration 으로 접속 테스트


3. gradle 설정

[Jenkins 관리] - [Global Tool Configuration]

- Install automatically > 체크 원하는 버전 선택



freestyle project



1. freestyle project 생성

[새로운 Item] - [freestyle project]


2. 소스 코드 관리

- Git Repository URL 정보 입력


3. Build

- Build : Invoke Gradle 선택


4. 빌드 후 조치

- Sned build artifacts over SSH 선택

- SSH Server Name : [시스템 설정]에서 구성한 타겟 서버 선택

- Source files : **/build/libs/*.war

- Remove prefix : /build/libs/

- Exec command :


sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
cs


5. Build Now

[Console Output] 에서 성공/실패 로그를 확인할 수 있다.


Started by user LeeHongKyu
Building in workspace /var/lib/jenkins/workspace/freestyle project
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/ggamzzak/javatest.git # timeout=10
Fetching upstream changes from https://github.com/ggamzzak/javatest.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/ggamzzak/javatest.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 7599f414e9beb11d4d1350e571b83b2290557465 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 7599f414e9beb11d4d1350e571b83b2290557465
 > git rev-list 7599f414e9beb11d4d1350e571b83b2290557465 # timeout=10
[Gradle] - Launching build.
[freestyle project] $ /var/lib/jenkins/tools/hudson.plugins.gradle.GradleInstallation/gradle33/bin/gradle
Starting a Gradle Daemon (subsequent builds will be faster)
:help
 
Welcome to Gradle 3.3.
 
To run a build, run gradle <task> ...
 
To see a list of available tasks, run gradle tasks
 
To see a list of command-line options, run gradle --help
 
To see more detail about a task, run gradle help --task <task>
 
BUILD SUCCESSFUL
 
Total time: 12.231 secs
Build step 'Invoke Gradle script' changed build result to SUCCESS
SSH: Connecting from host [ip-172-31-27-119]
SSH: Connecting with configuration [honghost1] ...
SSH: EXEC: STDOUT/STDERR from command [sudo service tomcat8 stop
sudo cp -ap web1-1.0-SNAPSHOT.war /var/lib/tomcat8/webapps/ROOT.war
sudo service tomcat8 start
] ...
Stopping tomcat8: [  OK  ]
Starting tomcat8: [  OK  ]
SSH: EXEC: completed after 2,003 ms
SSH: Disconnecting configuration [honghost1] ...
SSH: Transferred 1 file(s)
Finished: SUCCESS
cs


중간에 BUILD SUCCESSFUL 로 빌드가 성공한 것을 확인할 수 있고, 제일 마지막의 SUCCESS 로 모든 과정이 성공한 것을 확인할 수 있다.

타겟 서버에 접속해서 새로운 빌드 파일로 배포가 되었는지 확인한다.

지금까지 아주 기본적인 설정만을 선택하여 Git 소스 체크아웃 받고 gradle 로 소스를 빌드하고 타겟 서버에 빌드 파일을 업로드한 것을 확인할 수 있다.

저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

git reset

Tool/Git 2017. 2. 8. 00:22

git 에는 3가지 로컬 트리가 있다.


1. 워킹 디렉토리(WD)는 버전 관리 중인(tracked) 디렉토리/파일들 이다. 흔히 버전관리 작업하는 로컬 디렉토리라고 생각하면 된다.

2. Index(staged) 는 바로 다음에 커밋될 자료들이다.

3. HEAD 는 현재 브랜치 마지막 커밋의 스냅샷(포인터)이다.


우리가 워킹 디렉토리에서 파일들을 생성하거나 수정하고 커밋을 하기 위해 add 명령으로 index 에 올린 후, 이 자료들은 commit 시 HEAD 가 된다.



위 3가지 로컬 트리를 이해했다면 reset 을 쉽게 이해할 수 있다.

reset 명령은 HEAD 를 이동시킬 수 있다.

HEAD 는 가장 마지막 커밋을 참조하는 포인터이지만 reset 명령으로 해당 브랜치의 다른 커밋으로 옮길 수가 있다. (아마도 대부분 이전으로 옮기겠지..)


reset 명령에는 3가지 옵션이 있다. (soft, mixed, hard)


$ git reset --soft HEAD~
cs


HEAD~ 는 HEAD 의 이전 커밋을 가리킨다. (HEAD~2... 등이나 체크섬 사용 가능)

이전 커밋으로 HEAD 를 옮기는데 --soft 하게.

로컬 트리의 HEAD 만 이전 커밋으로 변경하라는 명령이다.

그 후 새로 commit 을 실행하면 git commit --amend 명령과 동일한 결과가 된다.

amend 는 마지막 커밋을 수정하지만, reset 은 훨씬 이전의 커밋을 수정할 수 있다.


$ git reset --mixed HEAD~
cs


이전 커밋으로 HEAD 를 옮기는데 --mixed 하게. (mixed 가 default 이다.)

로컬 트리의 HEAD 와 index 를 이전 커밋으로 변경하라는 명령이다.


$ git reset --hard HEAD~
cs


이전 커밋으로 HEAD 를 옮기는데 --hard 하게.

로컬 트리의 HEAD 와 index, WD 모두를 이전 커밋으로 변경하라는 명령이다.



위 예제처럼 전체가 아닌 특정 파일(paths)들을 reset 할 수도 있다.

특정 파일 때문에 HEAD 포인터가 바뀌지는 않으므로 HEAD 는 상태 그대로 고정된다.

mixed 옵션으로 Index 나 WD 는 일부분 갱신할 수 있다.


$ git reset file.txt
cs


위 명령은 tree-ish(commit, tag ...) 와 옵션을 생략한 git reset --mixed HEAD file.txt 의 줄임이다.





* 롤백하기



위 그림처럼 C4 까지의 커밋이 있었다고 치자.

원격 저장소의 origin/master 가 C4 를 가리키고 있었다고 치자.

그런데 C3 과 C4 의 내용이 잘못되어 C2 로 롤백해야 하는 상황이 발생했다고 치자.

이 경우 다음의 명령으로 롤백을 시킬 수 있다.


$ git reset --hard C2
cs


그리고 모든 팀원이 C3 과 C4 를 날리고 C2 의 새로운 가지에서 다시 작할 수 있도록 push 를 해보자.

우선 간단한 변경 사항을 만들어 commit(C5) 명령 후에 push 를 날려보자.

원격의 origin/master 는 C4 를 가리키고 있으므로 pull 을 받고 push 하라는 non-fast-forward 경고가 발생한다.


 ! [rejected]        master -> master (non-fast-forward)
cs


이 때 pull 을 받아 버리면 다시 로컬 저장소는 C4 를 가리키게 되므로 pull 을 받으면 안된다.

강제 push 로 C3 과 C4 를 날려버리고 origin/master 가 C5 를 가리키도록 아래와 같이 명령한다.


$ git push --force origin master
...
 + eaa2322...5efad42 master -> master (forced update)
cs


! [remote rejected] master -> master (TF401027: Your account lacks the permission(s) required for the operation you are attempting. 
You need to have 'For error: failed to push some refs to ...
cs


권한이 없다는 오류가 발생한다면, git 서버에 접속하여 다음 config 를 추가하면 된다.


$ git config receive.denyNonFastforwards false
cs


서버 관리자에게 권한 거부 당한다면 ㅈ망 ^^


이상!

저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

tracking to untracking

Tool/Git 2017. 2. 7. 22:56

.gitignore 파일은 버전관리 하지 않는(untracked) 파일을 버전관리 하지 않도록 무시할 수 있다.

하지만 깜빡하고 이미 버전관리(tracked) 에 포함이 됐거나 뒤늦게 .gitignore 파일에 추가했다면 tracked 파일은 무시되지 않는다.

이럴 때는 해당 파일을 삭제하고 커밋하는 방법도 있지만, 파일을 삭제하지 않고 tracked 파일을 untracked 파일로 변경하는 방법이 있다.


$ git rm --cached filename
cs


filename 에는 \* 같은 파일명 확장 기능을 사용할 수도 있다.

다음 명령은 log 디렉토리의 모든 log 확장자 파일들을 untracked 로 변경한다.


$ git rm --cached log/\*.log
cs


디렉토리와 디렉토리 내의 모든 파일은 간단하게.


$ git rm -r --cached log
cs




저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

git stash

Tool/Git 2017. 2. 6. 01:02

merge 를 하거나 branch 를 변경할 때 기존 작업물을 commit 하거나 stash 하라는 메시지를 볼 수 있다.

주로 임시적인 commit 을 행하곤 하는데, stash 라는 기능도 매우 유용하다.

요점만 말하자면 현재 수정된 tracked 파일들을 잠시 특정 공간(stack)으로 옮겨주는 역할을 한다.

그리고 나서 나중에 다시 되돌리면 끝이다.


$ git stash <- 수정된 tracked 파일을 잠시 옮김
 
$ git checkout other_branch <- 딴짓
$ git commit -m 'anything' <- 딴짓
$ git checkout ori_branch <- 딴짓
 
$ git stash apply <- 수정된 tracked 파일을 다시 가져옴
cs



재미진 기능이다.

아래의 명령으로 stash 된 리스트를 확인할 수 있다.


$ git stash list
stash@{0}: WIP on master: 049d078 added the index file
stash@{1}: WIP on master: c264051 Revert "added file_size"
stash@{2}: WIP on master: 21d80a5 added number to log
cs


특정 stash 리스트를 삭제할 수도 있다.


$ git stash drop stash@{0}
cs


apply 대신 아래의 명령을 사용하면 stash apply 후 바로 스택에서 제거하여 리스트에 남지 않는다.


$ git stash pop
cs



저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,

git amend

Tool/Git 2017. 2. 5. 00:44

마지막 커밋을 수정할 수 있는 방법이 있다. 바로 commit 명령의 amend 옵션을 사용하는 것이다.

'기능 추가 완료' 라고 당당하게 커밋 메시지를 추가했는데, 파일 몇개가 빠졌다면, 

혹은 '깅ㅡㄴ 추가 완료!' 이런식으로 메시지가 잘못됐을 때 사용할 수 있다.


$ git commit --amend -m '기능 추가 완료'
cs


라고 명령하면 현재 index(staged) 작업물들이 추가로 커밋되며 이전 커밋에 더해진다.


중요한 것은 commit 시 생성되는 체크섬(cabcbb5b1ac4e7593749e1853f21405ddacc7f88 같은...) 이 수정되므로,

이미 push 된 커밋이라면 수정하지 않는 것이 좋다.

이미 push 된 커밋을 부모(parent)로 하는 자식들이 있을 경우, 체크섬이 바뀌면서 부모 잃은 자식을 만들 수 있다.



저작자표시
WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.
,