1. 조사배경

 - git에서 gitlab으로 이전할 필요가 생겼음

2. 방법

  1) git 을 모두 다운 받고

    git clone --mirror 윈본git주소

 2) 해당 프로젝트로 이동

     cd {git 이름}

  3) gitlab으로 한다고 하고

   $git remote set-url --push origin 복사될git주소

  4) push 

   $git push --mirror

3. 특이사항

  1) 다음과 같은 에러 발생 후 push 안됨

   error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large

   ==> https를 통해서는 잘 안되었다. 그래서 git or ssh로 제공되는 git으로 이전해야 잘되었음

# 참고

https://struggler.tistory.com/205https://newtoynt.tistory.com/entry/gitlab%EC%97%90-migration-%ED%95%98%EA%B8%B0

awk

입력을 주어진 분리자(field seperator)로 분리하여 명령을 처리합니다.

주요 옵션

옵션설명

내장 함수

awk는 지정한 처리를 실행할 때 내장 함수를 이용할 수 있습니다.

함수설명

sub

$ echo "i have a water." | awk -F " " '{ sub("a", "b", $4); print $4 }'

wbter.

gsub

$ echo "i have a water." | awk -F " " '{ gsub("a", "b"); print $1" "$2" "$3" "$4 }'

i hbve b wbter.

index

$ echo "i have a water." | awk -F " " '{ print index($4, "a") }'

2

length

$ echo "i have a water." | awk -F " " '{ print length($4) }'

6

substr

$ echo "1234567890" | awk -F " " '{ print substr($1, 3, 2) }'

34

split

$ echo "A/B/C/D/E/F/G" | awk -F " " '{ print split($1, array, "/");print array[1];print array[3]; }'

7 A C

printf

$ echo | awk '{ printf("%.1f + %.2f = %.3f\n", 40.1, 20.2, 40.1 + 20.2); }'

40.1 + 20.20 = 60.300

사용예제

그룹의 합 구하기

그룹의 합을 구하는 것은 배열을 이용합니다. 배열의 인덱스를 키로 사용하여 값을 모두 더하여 주고 마지막에 출력하면 됩니다.

$ cat sample.txt a 1 b 2 a 4 c 1 c 2 $ cat sample.txt | awk '{ arr[$1] += $2 } END { for (i in arr) { print i, arr[i] } }'

a 5 b 2 c 3

합계(sum) 계산하기

합계는 지정한 인덱스의 값을 모두 더하여 구할 수 있습니다.

$ cat sample.txt | awk '{sum+=$2} END {print sum}'

10

문자열 자르기

문자열을 자를때는 내장함수 substr을 이용합니다.

$ echo "1234567890" | awk -F " " '{ print substr($1, 3, 2) }'

34

파라미터 전달

awk에 파라미터를 전달 할 때는 v 옵션을 이용합니다. v 옵션과 함께 이름=값 형태로 전달하고 내장함수에서 사용하면 됩니다.

root="/webroot" $ echo | awk -v r=$root '{ print "shell root value - " r}' shell root value - /webroot

마지막 편집일시 : 2019년 5월 9일 11:17 오전

# 참고

https://wikidocs.net/29643

1. 조사 이유 

  Task의 내용에 따라 실행 순서가 뒤죽 박죽이어야 의도된 결과를 얻지 못함

2. 요약

  1) Task

     task의 본문은 Configuration 단계이다 (맨 먼저 실행된다.)

    doFirst, doLast를 Execute 단계이다.

  즉 Task는 configuration > execute 순으로 하고 task들과는  dependsOn을 통해 순서를 정해 주어야 된다. (아니면 동시에 증분 실행된다.)

 * from 에 task를 주는 그런 방법도 존재한다.

   2) gradle 파일 실행 순서

    setting.gradle > build.gradle 순으로 실행 된다.

    setting.gradle <== 단순 설정들만 모아서 놓은 것이다. 그래서 이름도 setting이다.

3. 빌드시 기본 Task

4. 원문

들어가면서

Gradle이 5.0이 되면서 rc를 벗고 공식적으로 Kotlin을 빌드스크립트로 지원하기 시작했습니다. 스프링 프레임워크 또한 5에서 공식적으로 Kotlin을 지원하고 있습니다. 아직 gradle을 사용해 보지 않았다면 이제는 한번쯤 자세히 들여다 보기에 적절한 시점이라 생각합니다.

이에 Kotlin DSL을 기반으로 글의 작성 시점 기준 최신 버전인 5.1로 Gradle을 정리해 봅니다. 참고할 내용은 Gradle 공식 사이트의 Authoring Gradle Builds입니다. 오늘은 Understanding the Build Lifecycle를 읽고 요약합니다.

빌드 단계

Gradle은 3단계의 독립적인 과정을 갖고 있다.

초기화(Initialization)

Gradle은 단일 혹은 멀티 프로젝트 빌드를 지원한다. 이 단계에서는 빌드에 참여할 프로젝트를 확정하고 Project의 객체를 생성한다.

설정(Configuration)

이 단계에서 Project의 설정이 이뤄진다. 이 때 빌드에 포함된 모든 Project의 buildscript가 실행된다.

실행(Execution)

설정 단계에서 생성하여 구성한 Task의 잡합을 결정한다. 이 집합은 gradle 명렁으로 전달한 인자인 Task의 이름을 기준으로 결정된다. 이후 Gralde은 선택된 Task들을 실행할 것이다.

Settings 파일

Gradle은 buildscript 파일 외에도 설정과 관련된 파일도 있다. 관례에 따라 settings.gradle에 설정 정보를 선언한다. 추후 뒤에서 어떻게 Gradle이 설정 파일을 찾는지 알아본다.

설정 파일은 초기화 단계에서 실행된다. 멀티 프로젝트라면 반드시 settings.gradle 파일을 프로젝트 구조의 최상위인 루트에 두어야 한다. 멀티 프로젝트 빌드 시 설정 파일이 어떤 프로젝트가 포함되는지를 정의하기 때문에 필요하다. (자세한 건 Authoring Multi-Project Builds를 참조한다.) 단일 프로젝트의 빌드 시 설정 파일은 옵션이다. 멀티프로젝트에 포함될 프로젝트를 정의하는 것 외에도, 빌드스크립트의 클래스패스에 라이브러리를 포함시킬 수도 있다. (자세한 건 Organizing Gradle Projects 참조한다.)

우선 단일 프로젝트 예제를 통해서 스크립트의 실행 과정을 살펴보자

다음은 실제 출력 결과이다. 위에서 설명했듯이 초기화 단계의 첫 시작으로 설정 스크립트의 내용이 제일 먼저 출력된다. 이후 설정단계에서 buildscript를 읽으면서 스크립트에 선언된 두 줄의 문장이 실행된다. 이후 test, testBoth의 Action이 순차적으로 실행된다.

buildscript의 속성이나 메서드 호출이 모두 Project에 위임한 것처럼, 설정 스크립트도 속성이나 메서드 호출을 모두 Settings 객체에 위임한다. 자센한 내용은 Settings 클래스의 API 문서를 참조한다.

멀티 프로젝트 빌드

멀티 프로젝트 빌드란 한 번의 실행을 한 개 이상의 프로젝트를 빌드하는 경우를 의미한다. settings 파일에 멀티 프로젝트에 포함할 하위 프로젝트를 선언해야 한다. 멀티 프로젝트의 설정과 관련하여 자세한 내용은 Authoring Multi-Project Builds에서 살펴본다.

프로젝트 위치

멀티 프로젝트의 빌드는 항상 단일한 최상위 루트로부터 트리형태로 구성된다. 트리의 각 요소가 프로젝트이다. 멀티프로젝트 빌드 트리에서 각 프로젝트는 자신을 나타내는 경로를 갖는다. 대부분의 경우에는 물리적인 프로젝트 경로가 사용된다. (물론 다르게 구성할 수 있다.) 프로젝트의 트리는 settings.gradle에서 구성한다. 기본적으로 이 파일의 위치는 루트 프로젝트로 하지만 수정할 수 있다.

트리 구성하기

설정 파일에 프로젝트 트리를 구성하는 방법은 2가지가 있따. 1. 계층형 2. 단층형

계층형 레이아웃

include 메서드는 프로젝트의 경로를 인자로 받는다. 물리적인 파일 경로가 프로젝트의 경로가 된다. 예를 들어 services:api는 루트 프로젝트를 기준으로 services/api의 상대 경로에 대응된다. 프로젝트는 마지막 잎노드만 명시하면 된다. 예를 들어 services:hotels:api는 3개의 프로젝트 services, services:hotles, services:hotels:api를 포함한다. 자세한 예는 Settings.include(java.lang.String[])를 참고한다.

단층형 레이아웃

includeFlat 메서드는 디렉토리의 이름을 인자로 받는다. 프로젝트에 포함할 디렉토리가 반드시 루트 프로젝트의 자식이어야 한다. 이 디렉토리 위치는 멀티 프로젝트 트리에서 루트 프로젝터의 하위 프로젝트로 간주된다.

프로젝트 트리 요소 수정

설정 파일에 정의된 멀티 프로젝트 트리는 프로젝트 서술자라 불리는 것을 개념을 통해서 통해 구성한다. 설정파일에서 서술자를 언제든지 수정 가능하다. 예를 들어 서술자에 접근하는 방법은 다음과 같다.

서술자를 통해서 프로젝트의 이름, 경로 빌드 파일도 수정가능하다.

자세한 내용은 API 문서에서 ProjectDescriptor를 참조한다.

초기화

Gradle은 어떻게 단일 프로젝트인지 멀티 프로젝트인지 아는가? 만약 멀티 프로젝트 빌드를 설정 파일이 있는 위치에서 실행했다면 어렵지 않다. 하지만 Gradle은 하위 프로젝트 위치에서도 스크립트의 실행을 할 수 있다. 이러한 경우 Gradle은 settings.gradle.kts 파일을 찾기 위해 다음의 작업을 수행한다.

• 현재 디렉토리 레벨에서 찾는다.
• 그렇지 않으면 부모 디렉토를 찾는다.
• 찾지 못한 경우 단일 프로젝트로 실행한다.

설정 파일을 찾으면 Gradle은 현재 프로젝트가 멀티프로젝트 계층에 포함되는지 확인한다. 포함되어 있으면 멀티프로젝트로 그렇지 않으면 빌드는 단일 프로젝트로 진행된다. 이러한 과정의 목적은 무엇인가? Gradle 멀티 프로젝트에 포함된 하위 프로젝트 여부를 아는 것이 중요하기 때문이다. 하위 프로젝트라면 하위 프로젝트에 필요한 부분만 빌드한다. 하지만 전체 프로젝트의 설정은 필요로 한다. (자세한 내용은 Authoring Multi-Project Builds를 참고한다.).

만약 현재 프로젝트가 settings.gradle.kts를 가지고 있다면 빌드는 언제는 다음과 같이 진행된다.

• 단일 프로젝트 빌드: settings.gradle.kts에서 멀티 프로젝트의 계층을 구성하지 않았을 경우
• 멀티 프로젝트 빌드: settings.gradle.kts에서 멀티 프로젝트 계층을 구성한 경우

settings.gradle.kts을 자동으로 찾는 로직은 물리적으로 계층형 혹은 단층형 레이아웃 구조의 멀티 프로젝트일 때 이뤄진다. 단층형 레이아웃이라면 반드시 추가로 위에서 보여준 프로젝트의 명명 관례를 추가로 따라야 한다. Gradle은 멀티 프로젝트 빌드시 임의의 물리적인 레이아웃을 지원한다. 이 경우에는 설정 파일이 있는 위치에서 반드시 빌드를 실행해야 한다. 루트 경로에서 부분적으로 빌드하는 것과 관련해서 Running tasks by their absolute path를 참조한다.

Gradle은 빌드에 포함된느 모든 프로젝트에 대하여 Project 객체를 생성한다. 멀티 프로젝트 빌드에서 각 객체는 Settings 객체(와 루트 프로젝트)에서 구체화된다. 모든 프로젝트는 자신의 디렉토리명과 동일한 이르름을 기본으로 갖는다. 루트 프로젝트가 아니라면 자신의 부모 프로젝트를 갖기 마련이고 자신 프로젝트를 갖는 경우도 있다.

Configuration and execution of a single project build

단일 프로젝트의 설정과 실행

단일 프로젝트의 경우 초기화 이후 단계가 간단하다. 초기화 단계에서 생성한 Project객체를 바탕으로 빌드스크립트가 실행된다. 이 때 Gradle은 커맨드라인에 전달된 Task 들의 이름과 동일한 것을 찾는다. 동일한 이름의 Task를 찾은 경우 전달한 이름 순서대로 실행하되 별도의 빌드로 실행된다. 멀티프로젝트의 설정과 실행과 관련된 자세한 내용은 Authoring Multi-Project Builds를 참고한다.

빌드스크립트의 라이프사이클에 반응하기

빌드스크립트에서 라이프 사이클의 진행 과정을 전달받는 2가지 방법이 있다.

1. 특정 라이프 사이클의 리스너 인터페이스 구현
2. 특정 라이프 사이클이 호출될 때 클로저 구문을 전달

아례 예제는 클로저를 사용하는 경우이다. 리스터 인터페이스 구현은 API 문서를 참조한다.

프로젝트 평가 시점

프로젝트의 평가 전후에 알람을 받을 수 있다. 이 알람은 빌드스크립트에 모든 정의에 대하여 추가적인 설정을 한번 수행할 때 사용하거나 커스텀 로그나 프로파일링이 필요할 때 사용하기 좋다. 다음 예제는 hasTests속성을 참으로 갖는 모든 프로젝트에 테스트용 Task를 포함하는 예제이다.

위 예제에서는 Project.afterEvaluate()를 사용하여 프로젝트가 평가될 때 실행할 클로저를 추가했다.

항상 어떤 프로젝트라도 평가될 때 알람을 받는 방법도 있다. 이는 프로젝트의 평가와 관련된 커스텀한 로깅이 필요할 때 유용하다. afterProject 알람은 프로젝트의 평가의 성공여부와 상관없이 항상 실행된다는 점이 중요하다.

다음은 gradle -q test로 위 스크립트를 실행한 결과이다.

Task의 생성 시점

프로젝트에 Task를 추가한 후 알람을 받을 수도 있다. 이는 기본값을 추가하거나 Task를 빌드 파일에서 사용하기 전에 필요한 행위를 등록할 때 사용할 수 있다. 다음 예는 각 Task가 생성될 때 srcDir 속성을 정의한다.

이러한 이벤트를 전달 받기 위해 Action을 TaskContainer에 등록할 수도 있다.

Task 실행 그래프 준비된 시점

Task의 실행 그래프가 준비되었을 때 알람을 받을 수 있다. (추가로 Configure by DAG를 참조).

이러한 이벤트를 전달 받기 위해 TaskExecutionGraphListener을 TaskExecutionGraph에 등록할 수도 있다.

Task 실행 시점

Task의 실행 전후 시점에 알람을 받을 수 있다.

다음 예에서는 Task의 시작과 종료에 각각 로깅을 한다. afterTask 알람은 Task의 성공여부와 상관없이 실행된다는 점이 중요하다.

# 참고

https://not-for-me.io/post/gradle/04-build-lifecycle/