젠킨스 버전업이 이루어지면서 내부적으로 jdk 11 을 이용하게 되었다.

이때 젠킨스를 이용한 빌드시에 사용하는 remote 패키지가 11로 컴파일된거라 구버전의 젠킨스에서 빌드하던 jdk 8버전의 프로젝트들은 빌드시 remote.jar(jdk 11) 실행에 실패하면서 빌드가 실패나버린다.(내용은 버전 맞지 않음)

 

그럼 어떻게 해야할까?

 

우선 젠킨스자체의 메이븐 빌드 로 아이템을 만들지 말고, 프리스타일로 만든뒤

 

쉘로 직접 빌드하게 해주면되긴한다. 

 

쉘환경이 jdk 8 이면된다.

좀더 설명하면

 

1. jenkins build job 생성시 메이븐이아니라 프리스타일로 생성

2. 생성시 만들어진 이름으로, 빌드실행하면 젠킨스의 빌드노드 홈의, workspace 디렉토리 이하에 그 빌드아이템의 방이 생김

3. 해서... 우선 스크립트(execute shell) 는 비워두고 git 등의 정보를 입력하여 item 을 만들고, 그 item 을 빌드하면 생성한 item 이름으로 디렉토리가 생김. 

4. 그 디렉토리안에 보면 git 의 내용을 clone 해온걸 볼 수 있음

5. 여기서 단순히 jar 빌드이면 mvn 명령으로 빌드시킬수 있도록 직접 테스트 해보고 빌드 잘 되는 쉘 명령어를 item 의 execute shell 에 넣어주면됨.

6. 여기서 만약, 빌드 노드에 settings.xml 이 없다면 원래는 젠킨스의 아이템 생성시 메이븐 설정에 provided settings.xml 항목에 임의의 xml 을 정의해서 그걸 빌드에 사용하게 하는데, 우리는 쉘에서 하는거라 직접해줘야한다.

7. 해서 간단히, 해당 git 안에 그 프로젝트에 맞는 settingsl.xml 을 만들고 거기에 설정 넣어둔뒤 execute shell 실행시 실행될 mvn 옵션으로 -s settings.xml   처럼 맞는 xml 을 넣어주면된다.

 

아.. jenkins 의 파이프라인에서 환경변수 변경해서 ... 실행하는 방법이 있었는데;;;

 

바로 이럴때! chatgpt 에게 물어봤음  2024. 2. 27. 매우 간단하게 리마인드 가능했다.

 

 

Jenkins 파이프라인 스크립트에서 실행하는 콘솔의 환경 변수를 변경하려면, withEnv 스텝을 사용할 수 있습니다. withEnv 스텝은 특정 블록의 실행 동안 환경 변수를 임시로 설정하거나 수정할 수 있게 해줍니다. 이는 주로 steps 블록 내부에서 사용됩니다.

예를 들어, JAVA_HOME 환경 변수의 값을 변경하고 싶다면, 다음과 같이 withEnv 블록을 사용하여 해당 환경 변수에 새 값을 할당할 수 있습니다:

pipeline {
    agent any
    stages {
        stage('Set JAVA_HOME') {
            steps {
                // withEnv를 사용하여 JAVA_HOME 환경 변수 설정
                withEnv(["JAVA_HOME=/new/path/to/java"]) {
                    // 쉘 스크립트 또는 배치 스크립트를 실행하여 새 JAVA_HOME을 사용
                    sh 'echo $JAVA_HOME'
                    // 또는 Windows 배치 스크립트를 사용하는 경우
                    // bat 'echo %JAVA_HOME%'
                }
            }
        }
    }
}

 

이 예제에서, withEnv 블록 내부에서 JAVA_HOME 환경 변수는 /new/path/to/java로 설정됩니다. 이 변경은 withEnv 블록 내부에서만 유효하며, 블록을 벗어나면 원래 값(또는 설정되지 않은 경우)으로 복원됩니다.

sh 스텝은 Unix 기반 시스템(예: Linux, macOS)에서 쉘 스크립트를 실행할 때 사용되며, bat 스텝은 Windows 기반 시스템에서 배치 스크립트를 실행할 때 사용됩니다. 사용하는 Jenkins 노드의 운영 체제에 따라 적절한 스텝을 선택하세요.

withEnv를 사용하면 파이프라인의 특정 부분에서만 환경 변수를 변경할 수 있어, 파이프라인의 다른 부분에는 영향을 주지 않으면서 유연하게 환경을 제어할 수 있습니다.

git 사용중에 갑자기 editor 연결시 저런 에러가 난다면???

editor 를 다시 설정하는데 정확히는

 

git config --global core.editor vim -f

 

-f 옵션으로 vim 을 사용해라; 

 

https://stackoverflow.com/questions/22699614/git-commit-messages-lost-by-vi

 

Git commit messages lost by vi

I'm a clumsy typist, and I don't use vi/vim very often, but I do use it for commit messages. However, if you type a wrong command while editing a commit message (:Wq, say, instead of :wq), when you

stackoverflow.com

 

free software 인 dia 라는 다이아그램 툴이 있다. 개인적으로는 돈내고 살만한 가치의 무료소프트웨어인데...
어라...? 실행하면 실행안되고 실행환경?(정확하는 ) 인 xQuartz 만 뜬다.
확인해보니...

from http://navkirats.blogspot.com/2014/10/dia-diagram-mac-osx-yosemite-fix-i-use.html

Dia Diagram Mac OSX Yosemite Fix

I use the Dia tool for all my diagramming work. I have worked with many tools, but find Dia the easiest to use and is the most responsive, apart from it being a great OpenSource tool :).

I recently upgraded to the new Mac Operating System Yosemite and I could no longer use Dia. Each time I clicked on the Dia icon, it would jump up & down and do nothing. I finally tried opening the app via the command line, which gave me the following error:

The domain/default pair of (.GlobalPreferences, AppleCollationOrder) does not exist

The error trace ended with GTK warning - could not open display.

I could not find anything on the internet that was Dia specific, so I thought of writing this blog, in hope of helping someone in the same situation as me. So here is what I did:

Goto your Applications directory where Dia.app exists (mine was located at: /Applications)
Right click the icon and click on Show Package Contents
Goto the directory Dia.app/Contents/Resources/bin
Edit the file dia, in your favourite text editor.
After line 39, add the line: export DISPLAY=:0
Save and exit.
Close XQuartz if its running.
Now Dia should come up.
If it does not come up, try restarting your computer.
If not, try and add the line - export DISPLAY=:0 to your ~/.bash_profile, re-login and hopefully you should have Dia working once again.

Let me know if this helped you out :)

아.. display 문제였구나.  큰 도움이됐다! 요세.. 말고 그 뒤의 운영체제에서도 잘 되는듯 하다. 어차피 해당 내용이 원인이라면 안되는게 이상할듯 

이런 어마어마한 툴을 무료로 풀어주신 마소에게 감사드리며...

 

정말 어마어마한 확장성을 가진 visual studio code (이하 비주얼코드) 는 다양한 언어 및 툴의 설정파일등에 대해 extension 이라는 기능을 제공하여 해당 언어등에 맞는 환경을 제공한다.

 

당장에 docker 나 k8s, java, python 등 다양한 언어를 지원하고 있다. extension 만 설치하면된다.

 

글쓴이가 주로 설치하는 방법은 다음과 같다.  참고로 직접 검색해도 된다. 근데 뭔가 자동화라는 느낌이 나는걸 보고 싶다면 따라해봐라.

 

우선 만약 python 의 extension 을 설치하고 싶으면..

 

1. File > New File 선택
2. 저장 선택
3. 파일명은 아무렇게나 하고 확장자를 .py 로 하고 저장
    순간 아래에 extension 에 대한 install 을 물어오는 다이얼로그가 뜬다. 그대로 진행하면된다.

 

 

그럼 도커는?

역시 새파일을 만들고 저장시 Dockerfile 이라고 저장하면 아래에 역시 도커에 대한 extension 이 뜬다.

 

k8s?

확장자를  .yaml 로 저장하면 역시 아래에 뜬다.

 

즉 직접 검색해서 설치할 필요도 없이 해당 언어 및 툴의 설정파일 명 및 확장자의 파일로 저장하거나 읽어오면 알맞은 extension 설치를 물어온다.


REBASE 는... 말그대로 RE - BASE .. 내가 만들어진 부모(BASE)를 재정의(RE)하는것이다. 재정의하게 되면 내가 알고 있던 부모(old)로부터 바뀌어진 있는 부모(new)의 수정 내용이 나에게 적용된다. 


흡사 처음부터 난 바뀌어진 부모(new)로 부터 만들어진것 처럼.. 말이다. 부모의 수정본이 그대로 나에게 적용되는것이다. 예로 내가 작업중인데 중간에 상용에 hotfix 가 적용된 경우 그 적용본을 나에게 적용해야할때, rebase 를 하면된다.(누구를 대상으로 rebase 하냐고? rebase로 가져올(작업으로 머지할.. 내작업..한 소스로 들어올) 대상에게 rebase  한다. 즉 내 작업으로 checkout 된 상태에서 git rebase master or develop 이런거지. onto master 이다. )


그리고 항상 언급되는 얘기인데, rebase 는 히스토리의 수정이 들어가므로


push 한 커밋을  rebase 하진 마라. 내가 새로 한 작업(push 되지 않은 commit)을 rebase 하는건 문제 없다. push 한것을 rebase 했다간 내가 push 한걸 가져간 누군가의 작업을 망쳐버릴 수 있다.


출처: https://ezsnote.tistory.com/entry/왜-rebase



아래는 단계별로 예를 든 것이다.



1. develop 으로 부터 2개의 브랜치를 만든다. 하나는 newHotFix, 하나는 newFun01

2. newHotFix 에 4번의 커밋을 한다. 히스토리상 4개의 커밋이 보이겠지. 

3. newHotFix 를 이제 develop 에 반영하자. 


rebase 는 나의 base 를 다시 재정의 하는것이다.

이걸 언제 쓰냐고? 간단히 내가 만든 브랜치의 부모인 master/develop 이 다른 배포와 머지가 되어버린 상태일때,

즉, 내가 브랜치 만들때와 다르게 상태가 바뀌었다면 그때 나의 브랜치의 부모를 새로운 master/develop 로 하는게 rebase 라고 봐도 된다. 


위의 내용중 newHotFix 를 develop 에 적용하자. (즉 머지)

(참고로 newHotFix 에서 develop/master 로 rebase 해봤자 변화는 없다... 내가 알던 부모가 그대로거든)


5. 이제 newFun01 이 알던 develop/master 가 아니다. newHotFix 와 머지됐거든

   새로운 부모로 rebase 하자. 

   git checkout newFun01

   git rebase develop


   하면 newHotFix 의 내용이 newFun01 에 들어가 있다. 새로운 부모로 base 를 새로 짰으니 그 수정분이 newFun01 에 들어온것이다.


6. 이때 상태를 보면.. push 할것과 pull 할게 생겨있다. 현재브랜치는 newFun01 이다. pull 하면 어떤일이 생길까?

   rebase 를 했을때 상태를 보면 newFun01 은 newHotFix 가 적용되었고 그 위치에 있다. 여기서 pull 을 하면 newHotFix 분이 현재가 아닌 과거로 밀려나고 현재 새로운 수정본위치로 head 가 옮겨진걸 볼 수 있다. 즉 히스토리가 반영되는것이라고 봐도 된다. 마치 hotfix 가 적용된 이후의 develop/master 로 부터 브랜치를 만든것처럼 된다. 

   이제 push 하자.

   git push 


7. 자.. 이제 히스토리를 보면 같은 부모로 부터 만든 hotFix / newFun 의 위치가 hotFix 가 먼저 적용되고 이후에 newFun 을 만들어 작업한것 처럼 보이게 생성되어있다. 동시에 같은 부모가 아니라 하나의 작업이 끝나고 그다음 다른 피처를 만들어 머지한것처럼..


   




설정 > data formats > type 을 number(숫자) 로 해두고 use grouping 체크를 해제하면 된다.



가끔 eclipse 에 svn 으로 부터 가져온 프로젝트의 svn 연결이 끊어지는 경우가 있다. (svn 설정파일은 멀쩡히 존재함)

이럴때 재연결하는 방법은 해당 저장소에서 다시 체크아웃해서 다 당겨와야하는데 이것도 은근히 시간 많이 걸린다. 이럴때는 재연결할 수 있다.


해당 프로젝트를 고르고 svn > share project (s 가 아니다... 하나만 할꺼라서) -> 선택하면 이제 아마... 남아있는 svn 정보를 이용해서 알맞은 저장소를 알려주는것 같다. 확인이던가를 누르면 다시 연결된다.




+ Recent posts