Libelektra: 서버 항목 구축

@markus2330

몇 가지 빌드 시스템 관련 수정 사항을 푸시했습니다. 그러나 안정적인 debian-stable 시스템에서도 일부 패키지를 수정해야 합니다.

• wheezy-backports에서 qtdeclarative5-dev를 설치하십시오(나중에 /opt/Qt5.3.0을 제거할 수 있음)
• java8을 패키지로 설치하십시오:
  
  
  
  • 이 방법을 사용하십시오: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • cmake가 실제로 jdk8을 찾도록 하십시오: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • kill + 로컬 jenkins Java 프로세스를 다시 시작하십시오. 그렇지 않으면 모든 빌드가 실패합니다
  
  
  • 선택 사항: jdk7 제거
  
  

문제를 해결해 주셔서 감사합니다.

또한 debian-stable 에이전트에서 해당 단계를 수행했습니다.

다른 시스템의 경우 qtdeclarative5-dev를 설치할 수 없었습니다. kde4에 필요한 qdbus와 충돌하기 때문입니다. 그래서 이전 스크립트 configure-debian-wheezy를 configure-debian-wheezy-local로 복원했습니다.

또한 다른 사람들이 관심을 가질 수 있기 때문에 README.md에 메모로 언급한 설치 단계를 추가했습니다.

에이전트를 업그레이드해 주셔서 감사합니다!

마구간에서 빠진 것들

1.) 라텍스 (+ texlive-latex-recommended도 필요하다고 생각합니다)
http://build.libelektra.org:8080/job/elektra-doc/495/console 참조

-- Found Doxygen: /usr/bin/doxygen (found version "1.8.8") 
CMake Warning at doc/CMakeLists.txt:46 (message):
  Latex not found, PDF Manual can't be created.


-- Found Perl: /usr/bin/perl (found version "5.20.2") 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    BUILD_EXAMPLES

2.) clang을 설치할 수 있습니까(elektra-clang의 경우, clang of wheezy는 작동하지 않음)?
3.) elektra-gcc-configure-mingw에 mingw+wine을 설치할 수 있습니까?

apt install --no-install-recommends doxygen-latex + clang + mingw 완료

왜 와인이 필요합니까?

BTW, 당신은 변경해야합니다 i586-mingw32msvc-X 에 i686-w64-mingw32-X 에서 Toolchain-mingw32.cmake . 지금은 불안정한 상태에서 작동하지 않습니다.

다큐 감사합니다!

와인은 교차 컴파일된 Windows 바이너리(예: exporterrors.exe)를 실행하는 데 필요합니다.

w64용으로 빌드된 mingw를 설치한 것 같습니다. mingw32 패키지에는 여전히 /usr/bin/i586-mingw32msvc-c++ 있습니다.

그럼에도 불구하고 w64용 새 도구 모음 파일은 높이 평가됩니다.

i686을 대상으로 하는 mingw의 x64 빌드인 gcc-mingw-w64-i686 를 설치했습니다.
mingw32-binutils 패키지는 더 이상 사용되지 않으며 불안정한 환경에서 더 이상 사용할 수 없습니다.

두 용기에 모두 와인을 설치했습니다.

사실, mingw 빌드는 안정적이어야 하므로 문제가 되지 않습니다.

MinGW-w64는 mingw의 포크이며 완전히 다른 대상입니다. 지금까지 아무도 테스트하지 않았습니다.

와인을 설치해주셔서 감사합니다

Mingw-w64가 우월해 보입니다. 진행해야 하는 시점이 아닐까 합니다 :-)

기여 환영 ;) 테스트할 기계가 없습니다.

나는 당신이 잘못된 와인을 가지고 있다고 생각합니다. 그것은 apt-get install wine32여야 합니다.

http://build.libelektra.org:8080/job/elektra-gcc-configure-mingw/218/console 참조

아니요.

root@debian-stable:~# apt-get install wine32
....
E: Package 'wine32' has no installation candidate

알겠습니다. dpkg --add-architecture i386 이 문제를 해결할 것입니다. 하지만 mingw/wine 작업을 빌드 머신에 고정할 수 없습니까? mingw 설정은 다소 특별합니다.

편집: mingw-w64로 elektra 빌드를 얻을 수 있는지 확인하여 수많은 i686 라이브러리를 설치할 필요가 없습니다.

문제는 여분의 제시 머신이 없고 wheezy의 mingw가 C++11을 모른다는 것입니다.

mingw-w64를 작동시키는 데 성공했습니다. 그러나 std::mutex는 Windows에 glibc가 없고 std::mutex가 pthread에 의존하기 때문에 사용할 수 없습니다. 어떤 아이디어?

와 고마워!

컴파일 오류가 발생합니까? std::mutex는 내부용으로 사용되지 않습니다.
그러나 사용자가 포함할 헤더 파일에만 있습니다. 사용된다
하지만 테스트 케이스에서.

컴파일 문제에 대한 한 가지 해결책은 mingw에 std::mutex를 제공하는 것입니다.
잠금/잠금 해제를 시도할 때마다 시스템 오류가 발생하는 경우. 사실, 나는
mingw 사람들이 최소한 이와 같은 것을 제공할 것으로 기대합니다(예:
-D_GLIBCXX_USE_NANOSLEEP와 유사한 일부 매크로가 설정됨)

https://github.com/meganz/mingw-std-threads 는 다른 방법일 수 있습니다. 하지만 그건
std::mutex와 관련된 테스트 케이스를 제외한 모든 테스트 케이스에서만 유용할 가능성이 높습니다.
이미 실행.

기본적으로 이것은 제대로 사용할 수 없는 C++11의 한 인스턴스일 뿐입니다.

현재 mingw 상태:

• libloader에 외부 프로젝트로 dlfcn-win32를 추가했습니다. 이 방법으로 cmake는 추가 빌드 단계로 라이브러리를 체크아웃하고 컴파일합니다. 추가 dll deps를 피하기 위해 아카이브를 연결하고 있습니다.
• cpp11_benchmark_thread에 winsock2.h/ws2_32.dll 종속성을 추가했습니다. gethostname() 호출에 필요

지금은 -static-libgcc + -static-libstdc++ 빌드 중입니다. 그렇지 않으면 와인이 dll을 찾을 수 없습니다. 추가 뮤텍스도 컴파일되지 않습니다. 나는 mingw-std-threads를 시도했다. 더 많은 컴파일 오류가 발생했습니다 :-)

x86_64-w64-mingw32-X 에서 x86_64-w64-mingw32-X-posix 하면 pthread 항목이 정의되어 있기 때문에 std::mutex가 잘 컴파일됩니다. 그러나 와인이 찾을 수 없는 libwinpthread-1.dll에 대한 추가 종속성이 발생합니다.

하지만 가장 좋은 방법은 x86_64-w64-mingw32-X-posix 것입니다.

다시 말하지만, 나는 당신이 심지어이 문제를 가지고 있다는 것에 놀랐습니다. 지금까지 우리는 libelektra.dll을 얻었을 때 기뻤습니다.

나는 이 x86_64-w64-mingw32-X-posix 결정에 대해 아무 말도 할 수 없습니다. 왜냐하면 저는 그것을 사용하지 않고 그 의미를 알지 못하기 때문입니다. 그런 posix-lib가 존재하는지 궁금합니다. posix-layer 접근 방식이 mingw가 아니라 cygwin이라고 생각했습니다.

이 결정이 libelektra.dll에도 영향을 줍니까? 테스트 케이스만을 위한 것이라면 아무도 신경 쓰지 않을 것입니다(빌드 서버가 그것을 실행할 수 있는 한). 테스트 케이스가 실행되면 큰 이점이 될 것입니다. (단위 테스트가 Mac OS X에서 몇 가지 이상한 버그를 공개한 #270 참조)

libwinpthread-1.dll 다운 가능한 것 같은데, 와인과 연동이 되는지 모르겠네요? dlfcn-win32로 수행한 것처럼 외부 프로젝트로 추가할 수도 있습니까(모든 dll이 동일한 방식으로 처리되도록)? 그렇지 않으면 테스트를 위해 1개 또는 3개의 dll을 다운로드해야 하는 경우 실제로 중요하지 않을 수 있습니다(다시 말하지만 저는 사용자가 아니며 Windows dll의 배포 개념(있는 경우)을 이해하지 못합니다.

@beku 어떻게 생각해? oyranos와 함께 Windows에서 최신 0.8.13 mingw-w64 빌드를 테스트할 시간이 있습니까?

일반적으로 mingw 빌드 작업에 대해 테스트가 활성화되어 있습니까? 어제 그들 모두가 비활성화되었습니다.

예, 그들은 장애인이었습니다. 그러나 cpp11_benchmark_thread 와 같은 afaik 예제/벤치마크도 비활성화되었습니다. 그래서 이전보다 더 많이 변경하고 컴파일한다고 생각했습니다.

C++11이 활성화된 상태에서 전체 저장소를 컴파일했습니다. 더 이상 아무것도 없습니다.

그러나 -posix로 빌드된 bin/basename.exe와 같은 실행 파일은 필요한 dll을 bin 디렉토리에 복사하기만 하면 잘 실행됩니다(RPATH가 없는 Windows에 감사드립니다). a) cmake가 dll 디렉토리를 찾도록 하고 b) wine이 dll 디렉토리를 가리키도록 하는 방법을 찾지 못했습니다.
정적 연결이 작동할 것이라고 생각했지만 elektra dll을 연결하는 동안 중복 기호로 빌드가 실패합니다. dll에는 이미 기호가 포함되어 있기 때문입니다.

@markus2330 나는 dll을 복사하지 않고 와인과 함께 실행하는 mingw로 elektra를 컴파일할 수 있었습니다. 트릭은 실행 가능 개체와 공유 개체( CMAKE_SHARED_LINKER_FLAGS / CMAKE_EXE_LINKER_FLAGS => " -static ") 모두에 대해 정적 링크를 항상 활성화하는 것입니다.

중복된 기호를 해결하기 위해 libelektra 및 libelektratools용 버전 스크립트를 추가했습니다. 이렇게 하면 심볼만 내보내집니다.

이것은 정말 잘 작동합니다. 예

$ wine64 ./bin/kdb-static.exe
Usage: Z:\home\manuel\build\bin\kdb-static.exe <command> [args]

Z:\home\manuel\build\bin\kdb-static.exe is a program to manage elektra's key database.
Run a command with -H or --help as args to show a help text for
a specific command.

Known commands are:
check   Do some basic checks on a plugin.
convert Convert configuration.
cp      Copy keys within the key database.
export  Export configuration from the key database.
file    Prints the file where a key is located.
fstab   Create a new fstab entry.
get     Get the value of an individual key.
[...]

$ wine64 bin/cpp_example_iter.exe
user/key3/1
user/key3/2
user/key3/3

bin/cpp11_benchmark_thread.exe도 작동합니다.

다른 것들은 그냥 충돌:

$ wine64 ./bin/kdb-static.exe get
wine: Unhandled page fault on read access to 0x00000000 at address 0x7fd0e8b62c8a (thread 0009), starting debugger...
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
Unhandled exception: page fault on read access to 0x00000000 in 64-bit code (0x00007fd0e8b62c8a).
Register dump:
 rip:00007fd0e8b62c8a rsp:000000000033f428 rbp:0000000000000000 eflags:00010293 (  R- --  I S -A- -C)
 rax:0000000000000000 rbx:000000000033f700 rcx:0000000000000000 rdx:000000000033f5b0
 rsi:0000000000000000 rdi:0000000000000000  r8:0000000000000000  r9:0000000000000072 r10:0000000000000000
 r11:000000000003f615 r12:000000000033f5b0 r13:00000000000373b0 r14:0000000000000000 r15:000000000033f930
Stack dump:
0x000000000033f428:  00007fd0e748ea93 0000000000000000
0x000000000033f438:  0000000000000000 0000000000000000
0x000000000033f448:  0000000000000028 0000000000010020
0x000000000033f458:  8d98315017c96400 6f46746547485300
0x000000000033f468:  687461507265646c 0000000000000000
0x000000000033f478:  0000000000000000 0000000000000000
0x000000000033f488:  000000000003fab0 0000000000030000
0x000000000033f498:  8d98315017c96400 6f46746547485300
0x000000000033f4a8:  687461507265646c 0000000000000000
0x000000000033f4b8:  0000000000000000 0000000000000000
0x000000000033f4c8:  0000000000000000 0000000000000000
0x000000000033f4d8:  0000000000000000 0000000000000000
Backtrace:
=>0 0x00007fd0e8b62c8a strlen+0x2a() in libc.so.6 (0x0000000000000000)
  1 0x00007fd0e748ea93 MSVCRT_stat64+0x92() in msvcrt (0x0000000000000000)
  2 0x00000000004744af in kdb-static (+0x744ae) (0x000000000003f9d0)
  3 0x000000000043bda5 in kdb-static (+0x3bda4) (0x000000000003f9d0)
  4 0x0000000000431d76 in kdb-static (+0x31d75) (0x00000000000360a0)
[...]

지금은 다른 컴파일러에 대해 생각하지 않고 단순히 버전 스크립트 항목을 추가했습니다. 나는 일을 계속할 것인가, 아니면 관심을 갖지 않을 것인가?

pk->filename이 NULL이기 때문에 src/plugins/wresolver/wresolver.c에서 충돌이 발생합니다.

pk는 resolverHandles.user

플러그인을 살펴보려고 했지만 elektraWresolverOpen 의 for 루프를 이해하지 못했습니다. 루프는 elektraWresolveFileName --> elektraResolve{Spec,Dir,User,System} 를 호출하며 모든 malloc은 resolverHandle->filename 이므로 메모리가 누출됩니다.

지적해주셔서 감사합니다! 코드는 c87ae8e87a716b02b2c7ed790ad56a89d95547a9에 도입된 이후 분명히 깨졌습니다.
루핑 동안에만 항상 시스템 핸들이 초기화되었습니다. 이로 인해 다른 네임스페이스가 사용될 때 충돌이 발생합니다.

나는 그것을 고쳤다.
edb4d50856bb5331749220de5a83fa2062624a9d

계속 작업에 대해: 한편으로는 컴파일된 항목도 실행되면 좋을 것입니다. 반면에 릴리스는 이번 주말에 이루어져야 하므로 pull 요청이 곧 중요할 것입니다(예: 버전 스크립트가 실제로 수행하는 작업과 같은 짧은 피드백 서클의 기회가 최소한 있어야 함)

그러나 하나의 변형(정적 컴파일)만 작동하면 충분합니다. kdb-tool이 실행되는 것을 보는 것이 좋습니다!

edb4d50856bb5331749220de5a83fa2062624a9d는 어디에서 찾을 수 있습니까?

edb4d50856bb5331749220de5a83fa2062624a9d가 조금 늦게 푸시되었습니다.

debian-unstable-mm에 어떤 gcc 버전이 설치되어 있습니까?

http://build.libelektra.org :8080/job/elektra-multiconfig-gcc-unstable/build_type=Release,gcc_version=5.2,plugins=ALL/56/console

gcc-5.2가 없다고 합니다

가능한 한 많은 컴파일러를 설치할 수 있습니까?

어떤 문제나 PR에서 나는 최신 컴파일러를 제외한 모든 컴파일러를 제거했다고 말했습니다.
편집: 안정에서 gcc 4.9, 불안정에서 4.9 + 5.x(기본값)

자신의 컨테이너에서 이러한 종류의 테스트를 수행하십시오(어쨌든 매우 불필요하다고 생각합니다). 내 것은 어쨌든 영원히 머물지 않을 것입니다.

나는 그것을 읽지 않았다. 각각 50MB 정도 있습니다. 다시 설치하고 첫 번째 질문에 답해 주시겠습니까?

아마 우리 모임에서 말했을 것입니다. 그러나 나는 분명히 당신에게 말했습니다.

debian-unstable:~ # gcc -v 2>&1 | tail -n 1
gcc version 5.2.1 20150903 (Debian 5.2.1-16)

버전별 바이너리를 gcc-5라고 합니다. 마이너 버전을 위한 별도의 패키지는 더 이상 없습니다. 따라서 이 수준의 세부 정보가 포함된 multiconfig-gcc는 구식입니다. gcc 4.7을 제거하고 gcc-5.2를 gcc-5로 교체하고 완료하는 것이 좋습니다.

내가 설치하지 않은 유일한 추가 컴파일러는 gcc-4.8입니다. 그리고 gcc-4.8은 이미 제거 태그가 지정되었습니다.

정보에 대해서 감사드립니다! 사용 가능한 많은 컴파일러의 전성기가 끝난 것 같습니다.

multiconfig-unstable을 수정했습니다.

훌륭한 에이전트 설정 덕분에 지금은 닫겠습니다.

안녕하세요, jessie(stable)는 패키지가 더 필요합니다. 다음을 설치해 주시겠습니까?

• [ ] 가짜 루트
• [ ] gpg(+ Autobuilder [email protected]용 키 생성)
• [ ] reprepro(이미 설치되었을 수 있음, 스크립트가 아직 진행되지 않음)

fakeroot가 설치되어 있고 gpg + repro가 이미 설치되어 있습니다.
이미 존재하는 gpg 키를 메일로 보내주시겠습니까? 따라서 두 빌드 머신은 동일합니다.

다른 gpg 키를 갖는 것이 좋습니다. 현재 설정에서 사용하는지 확실하지 않으므로 먼저 http://build.libelektra.org :8080/job/elektra-git-buildpackage-jessie/2/가 실패하면 기다리십시오.

• debhelper + libsystemd-journal-dev 설치
• python-dev는 잘못된 종속성입니다. python2.7-dev 또는 python3-dev 또는 둘 다여야 합니다.
• 왜 파이썬 지원이 필요한가요?

설치해주셔서 감사합니다!

python-dev 은 Jessie 및 python-support 에도 사용할 수 있습니다. 설치하십시오.

로컬에서 테스트했는데 이러한 패키지가 설치되면 jessie용으로 빌드됩니다.

물론 사용 가능하지만 잘못된 종속성입니다. python-dev는 _not_ 충분하지 않은 python2.7-dev에 의존합니다. 대신 python2.7-dev + python3-dev가 필요합니다.

python 지원은 전혀 필요하지 않습니다.

종속성이 왜 이런 식으로 선택되었는지 모르겠지만 대부분의 패키징은 gsoc 동안 @iandonnelly에서 수행되었습니다.

예, python3 바인딩을 빌드하려면 패키지도 업데이트해야 합니다. 현재, 단순히 완료되지 않았습니다. 그럼에도 불구하고 빌드가 중단되지 않도록 python3-dev를 설치할 수 있습니다(python3 바인딩+플러그인이 데비안 패키지에 추가될 때).

그것이 그들이 정확하다는 것을 의미하지는 않습니다 :-) - 저는 python-dev deps에 대해 상당히 확신합니다.
그것들을 교체하고 python-support dep를 제거할 수 있습니까?

python3-dev 및 python2.7-dev가 이미 설치되어 있습니다. 그렇지 않으면 바인딩이 빌드되지 않습니다.

ㅋ @pinotree 의 공식 데비안 패키지는 python3 전용을 빌드합니다. "debian" 브랜치에서 수정하는 것은 시간 낭비일 것입니다. @pinotree 의 작업은 어쨌든 우수합니다.

시간이 되면 "debian" 브랜치를 @pinotree 가 공식 패키지에서 수행한 것으로 업데이트하겠습니다. 그분은 이미 우리가 그렇게 하도록 허락하셨습니다. qt-gui 업데이트를 기다리겠습니다. 현재 변경하는 데 서두르지는 않습니다. 그리고 python2를 지원하는 것은 한 번의 설치에 중요합니다(치타가 사용되는 곳, python3에서는 작동하지 않음).

나는 python2 패키지를 제거하겠다고 말한 적이 없습니다. 내가 말하는 것은 python-dev가 부정확한 종속성이라는 것입니다. 명시적 버전이 필요합니다. 따라서 pythonX-dev가 사용하기에 올바른 dep입니다.

바라건대 pinotree는 종속성을 올바르게 해결했습니다.

Btw, 치타는 죽었다. 사용하지 마십시오.

알겠습니다. 교체했습니다. b7c266b36b0ab0fad9120e67a457b580c7c44690을 되돌리고 필요한 경우 python-support를 설치하십시오.

나는 pinotree가 그것을 올바르게 수행했다고 확신합니다 ;)

그리고 그것은 말합니다: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org :8080/job/elektra-git-buildpackage-jessie/3/console

설치된

python-dev는 잘못된 종속성입니다. python2.7-dev 또는 python3-dev 또는 둘 다여야 합니다.

• python-dev 는 기본 Python 2 버전용 개발 패키지를 설치합니다. Wheezy 이후로 이것은 Python 2.7입니다.
• python3-dev 는 기본 Python 3 버전용 개발 패키지를 설치합니다. Wheezy의 Python 3.2, Jessie의 3.4, 지금까지 Stretch의 3.4(곧 3.5가 될 것 같습니다)

따라서 기본 Python 2/3 버전에 대해 빌드하려면 pythonX.Y-dev 버전이 아니라 각각 python-dev / python3-dev 를 사용하십시오(명시적으로 시스템에 설치된 유일한 버전이 아니라 기본 버전이 아닌 경우에도 정확한 Python 버전이 설치되기를 원합니다. 둘 중 하나를 사용하는 것이 좋습니다.

python-dev 설명:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

이 텍스트에 따르면 python-dev는 곧 python3에 확실히 의존할 수 있습니다.

더 나아가: 다른 python2 버전은 없을 것입니다. 따라서 python2.7-dev는 마지막 python2 dev 패키지가 될 것입니다.

python3-dev에 따라 내가 말한 것입니다.

이제 키만 누락되었습니다.

gpg: new configuration file `/home/jenkins/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/jenkins/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/home/jenkins/.gnupg/secring.gpg' created
gpg: keyring `/home/jenkins/.gnupg/pubring.gpg' created
gpg: skipped "Autobuilder <[email protected]>": secret key not available
gpg: /tmp/debsign.DlSdnFtB/elektra_0.8.13-1.41.dsc: clearsign failed: secret key not available
debsign: gpg error occurred!  Aborting....

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   2048R/08C91995 2015-09-30
      Key fingerprint = BA4C 688E 9071 FD3F 57ED  E9D6 D0A9 EDB9 08C9 1995
uid                  Autobuilder <[email protected]>
sub   2048R/E69F110A 2015-09-30

완료

감사합니다!

http를 통해 /home/jenkins/repository를 내보내십시오.

cannot access /home/jenkins/repository: No such file or directory ?

→ http://194.117.254.29/elektra-stable/

@manuelm 에이전트에 ronn 를 설치해 주시겠습니까? (맨페이지 생성에 필요)

apt-get install ruby-ronn

완료

감사합니다. jessie 패키지가 다시 빌드되고 이제 매뉴얼 페이지가 포함됩니다!

musl을 설치하십시오.

apt-get install musl musl-dev musl-tools

감사합니다!

musl 설치 및 agends 업그레이드

빌드 서버에 대한 두 가지 중요한 사항:

1. 빈 작업을 새로 만들지 말고 복제하십시오. 올바른 설정이 있습니다(2번에서 언급한 작업 제외).
2. 우리는 참조 클론(/home/jenkins/libelektra에 있음)을 사용하거나 모든 빌드 작업에 대해 얕은 클론을 선호해야 합니다(현재 elektra-clang과 같은 일부에 대해서만 수행됨). 현재 트래픽은 불필요한 재클론이 많기 때문에 커밋 시 >300MB입니다.

@mpranj 2를 고칠 수 있다면 좋을 것입니다.

@markus2330 확인을 위해: elektra-clang 있는 것처럼 모든 빌드 작업에 동일한 복제 동작을 적용해야 합니까?

다음을 제외한 모든 빌드 작업에 적용되는 얕은 클론:

• [ ] elektra-git-buildpackage-jessie
• [ ] elektra-git-buildpackage-wheezy
• [ ] elektra-multiconfig-gcc-stable
• [ ] elektra-multiconfig-gcc-불안정
• [ ] 엘렉트라 소스 패키지 테스트

이러한 작업은 일부 하위 디렉터리로 체크아웃됩니다. 당신이 거기에서 무엇을 원하는지 확신이 서지 않았으므로 지금은 그대로 두겠습니다.

감사합니다! 예, 완전한 기록과 분기가 필요합니다. 얕은 클론은 의미가 없지만 참조 클론 저장소가 유용할 것입니다.

Jenkins가 1.651.2로 업데이트되었습니다. 또한 모든 플러그인이 업데이트되었습니다.

참조 클론 저장소에 대해 문제를 계속 열어 두겠습니다. 또한 젠킨스 자체를 이상적으로 사용하여 수시로 repos를 업데이트하는 "cron 작업"도 있어야 합니다.

Jenkins는 일부 작업 구축을 중단했습니다(업데이트 이후). 그것은 실패한다
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

정보에 대해서 감사드립니다. github 요청 빌더를 1.31에서 1.14로 다운그레이드하려고 합니다.

이제 Github 커밋에 대한 빌드 상태를 설정할 때 멈춘 것 같습니다. 이것은 구성에서 더 이상 사용되지 않는다고 경고합니다.

또한 이름에 *git* 있는 모든 플러그인을 다운그레이드하려고 했지만 여전히 오류가 있었습니다(Mailer Plugin 관련 이상한 오류, Mailer Plugin 다운그레이드는 도움이 되지 않았습니다). 그래서 모든 것을 최신 버전으로 다시 업데이트했습니다. 문제는 업스트림에서 알려진 문제인 것 같습니다.

https://github.com/janinko/ghprb/issues/347

나는 그들이 곧 그것을 고칠 수 있기를 바랍니다.

또 다른 질문: 모든 PR에 대해 여러 작업을 실행하는 방법을 아는 사람이 있습니까? (나는 elektra-mergerequests-stable과 elektra-mergerequests-unstable을 모두 실행하고 싶습니다)

elektra-test-bindings 작업은 매개변수화된 빌드에서 제대로 작동합니다(업스트림 티켓에도 설명됨). 그냥 매개변수화된 빌드로 전환할 수 없습니까? 버그는 업스트림에 잠시 보고되었지만 곧 수정될 것 같지는 않습니다.

좋은 생각입니다. 모든 PR 작업을 매개변수화된 빌드로 변경할 수 있습니다. 실제로는 이점만 있습니다. 분기를 지정하여 작업을 수동으로 실행할 수도 있습니다. 또한 일반 빌드 작업에도 사용할 수 있습니다.

이상적으로 모든 작업은 github PR에서도 실행할 수 있습니다. (특히 마스터 브랜치의 문서 또는 적용 범위를 업데이트하는 비 PR 작업을 위한 작업 제외)

elektra-test-bindings 구성의 단점은 폴링만 수행하고 빌드를 시작할 때까지 시간이 상당히 오래 걸린다는 것입니다(최대 5분). 그러나 빌드 작업을 중단하지 않기 위해 "빌드 트리거에 github 후크 사용"을 활성화하고 싶지 않습니다.

ㅋ "shallow clone" 옵션이 github pullrequest 빌더 작업에 적합하다고 확신합니까?

github에서 새 PR에 사용하는 빌드 작업을 어떻게 선택하는지 궁금합니다. elektra-test-bindings 및 elektra-ini-mergerequests가 새 PR에 대해 선택되지 않은 이유는 무엇입니까? 때때로 elektra-mergerequests-unstable 및 때때로 elektra-mergerequests(-stable)인 이유는 무엇입니까?

@manuelm 혹시 생각이 있으신가요?

ㅋ 어떻게든 완성된 빌드 작업과 github의 통신이 심각하게 손상됩니다(elektra-test-bindings의 경우에도). 이제 거의 모든 빌드에서 "일부 검사가 아직 완료되지 않았습니다"라고 표시됩니다.

elektra-test-bindings 구성의 단점은 폴링만 수행하고 빌드를 시작할 때까지 시간이 상당히 오래 걸린다는 것입니다(최대 5분).

그리고 이것이 문제이기 때문에? 테스트는 어쨌든 5분 이상 걸립니다.

elektra-test-bindings 및 elektra-ini-mergerequests가 새 PR에 대해 선택되지 않은 이유는 무엇입니까?

왜 그래야 합니까? elektra-test-bindings 는 "트리거 구문"에 의해서만 트리거됩니다. elektra-ini-mergerequests 이(가) 무엇인지 모릅니다.

때때로 elektra-mergerequests-unstable 및 때때로 elektra-mergerequests-stable인 이유는 무엇입니까?

-stable/-unstable은 새로운 것입니까? 새 PR당 여러 작업을 트리거하는 것이 가능한지 잘 모르겠습니다. 나는 하위 작업을 할 것입니다.

Btw 이미 몇 번 말했지만 작업의 양이 점점 더 많아지고 있고 구성이 엉망이라는 신호라고 생각합니다. 그러나 비판은 항상 무언가를 해결하는 것보다 쉽습니다.

빌드 서버를 디버그하려는 경우 5분이 문제입니다. 그리고 나는 여전히 우리가 약 5분 정도 소요되는 빠른 첫 번째 테스트를 언젠가 받기를 희망합니다.

아, 알겠습니다. "빌드 트리거에 트리거 구문만 사용" 옵션을 놓쳤습니다. github 요청 빌더의 구성은 정말 엉망입니다.

누군가는 모든 PR에 대해 여러 작업을 실행하는 github 프로젝트에 대해 이야기했습니다. (개별적으로 표시됨)

부직이란 무엇입니까? 다중 작업을 의미

누군가는 모든 PR에 대해 여러 작업을 실행하는 github 프로젝트에 대해 이야기했습니다. (개별적으로 표시됨)

github에 두 개의 서비스를 추가해야 합니다.

부직이란 무엇입니까? 멀티잡을 말씀하시는건가요?

응 멀티잡.

btw, https://docs.travis-ci.com/은 어떻습니까? Travis는 OSX를 지원합니다.

나는 그것이 젠킨스를 대체하지 않을 것이라는 것을 알고 있지만 모든 커밋 빌드에서 PR을 대체할 수 있습니다. Jenkins는 여전히 여러 컴파일러/기타 테스트를 수행할 수 있습니다.
편집 : Travis에는 gcc + clang도 있습니다.

동의합니다. elektra가 오픈 소스이므로 CPU 전력/전기를 무료로 사용하는 것이 흥미로울 것입니다.

github과 jenkins의 연결은 실제로 1:1일 가능성이 높습니다. github 서비스에서 http://build.libelektra.org :8080/github-webhook/ 입력했는데 jenkins에서 다른 URL을 만드는 방법을 찾지 못했습니다. (오버라이드를 지정하는 방법만 찾았지만 새 URL은 생성되지 않았습니다.)

https://github.com/janinko/ghprb/issues/142에서 그들은 "그냥 작동"해야 한다고 논의합니다. (여러 서비스를 추가하지 않고)

그러나 sha1 문제는 지금 해결되어야 합니다. Jenkins가 알려지지 않은 환경 변수를 제거하는 새로운 보안 측정을 도입했기 때문에 문제가 발생했습니다. I는, 첨가 (제안 -Dhudson.model.ParametersAction.safeParameters = ghprbActualCommit, ghprbActualCommitAuthor, ghprbActualCommitAuthorEmail, ghprbAuthorRepoGitUrl, ghprbCommentBody, ghprbCredentialsId, ghprbGhRepository, ghprbPullAuthorEmail, ghprbPullAuthorLogin, ghprbPullAuthorLoginMention, ghprbPullDescription, ghprbPullId, ghprbPullLink, ghprbPullLongDescription, ghprbPullTitle, ghprbSourceBranch, ghprbTargetBranch으로 고정 ghprbTriggerAuthor,ghprbTriggerAuthorEmail,ghprbTriggerAuthorLogin,ghprbTriggerAuthorLoginMention,GIT_BRANCH,sha1 to /etc/default/jenkins).

추가 빌드 서버 사용 정보: 예, 계속 진행합니다. 또한 단일 PR에 대한 여러 빌드 작업의 문제를 해결합니다. 나는 travis가 ElektraInitiative에 액세스할 수 있는 권한을 부여했습니다.

첫 번째 트래비스 빌드: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Travis가 무엇을 해야 하는지 알 수 있도록 yaml 파일이 필요하다고 생각합니다.

그리고 PR당 여러 젠킨스 작업을 수행하는 방법을 알아냈고 모든 빌드 작업에 대해 다른 컨텍스트가 필요했습니다. 다음 회의에서는 "빠른" 및 기타 빌드 작업이 수행해야 하는 작업에 대해 논의합니다.

트래비스 작업 중(또는 몇 가지 확인 중)

즐거운 시간 보내세요. Travis도 github 서비스를 추가해서 PR도 travis로 구축할 거라 생각합니다.

난 이미 큰 소리로 맹세하고 있어

-- JNI를 찾을 수 없음(누락: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
-- jni를 찾을 수 없으므로 플러그인 jni 제외

Java 플러그인을 올바르게 구성할 수 없습니다. 그러나 Java 바인딩은 작동합니다. 불안정한 데비안에서. 어떤 아이디어? cmake 모듈을 보는 것은 별로 도움이 되지 않습니다.

편집: /usr/lib/jvm/java-8-openjdk-amd64/include/linux/jni_md.h , /usr/lib/jvm/java-8-openjdk-amd64/include/jawt.h 및 /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h 가 제자리에 있습니다.

편집 2: 알았습니다. JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-amd64/ ....

https://travis-ci.org/manuelm/libelektra/builds/130638376

도커 컨테이너 내에 구축된 불안정한 데비안. 그러나 건물을 짓는 데는 오랜 시간이 걸립니다.
좋은 아이디어가 있습니까?

clang은 종종 빌드 시간과 관련하여 더 빠르지 만 종속성을 설치하는 데 많은 시간이 걸린다고 생각합니다.

사용된 것보다 더 최소한의 데비안 도커 이미지가 있지 않습니까? 필요하지 않은 패키지가 많이 설치되는 것 같습니다.

@sirblackheart 그렇게 생각하는 이유는 무엇입니까? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm 아마도 dist-upgrade. wayland와 같은 데스크탑 전용 패키지가 많이 업데이트됩니다.

아니요. dist 업그레이드가 짧습니다. 아마도 분. 시간의 약 50%는 빌드 deps를 설치하는 데 소요됩니다.

지금 빌드 이미지를 hub.docker.com으로 푸시하고 있습니다. 속도가 빨라지길 바랍니다. 그러나 이미지에는 1.9GB가 있습니다.

경과 시간 14분 8초

우리가 훨씬 더 잘할 수 있는지 확실하지 않습니다

내가 말했듯이, clang은 우리에게 2-3분을 줍니다. 적어도 aseprite 프로젝트에서는 그렇습니다.
https://travis-ci.org/aseprite/aseprite

어쨌든 두 컴파일러를 모두 갖는 것이 유용할 것입니다.

작업을 준비하는 동안 아이디어가 떠올랐습니다. 푸시 요청에서 모든 커밋의 경로를 추출하고 영향을 받는 경우에만 바인딩/플러그인을 빌드하면 어떻게 될까요? 예

• cmake/*의 변경은 모든 것을 트리거합니다(플러그인 + 바인딩).
• src/bindings/foo에서 변경하면 바인딩 foo가 트리거됩니다.
• src/plugins/foo에서 변경하면 플러그인 foo가 트리거됩니다.
• 모든 것을 변경해도 플러그인 + 바인딩이 컴파일되지 않습니다.

우리는 여전히 젠킨스에 매일/두 번 전체 빌드를 가지고 있습니다.

@manuelm 좋은 생각입니다. @tom-wa가 그런 스크립트를 작성할 것입니다. 이에 대한 새 문제를 만들 수 있습니까?

@mpranj : 알림: Mac OS X 빌드를 travis에 추가하고 mingw 빌드를 PR에 추가하세요. (*BSD가 더 노력한 것 같습니다)

@markus2330 이제 @manuelm 도커 접근 방식을 이해합니다. travis는 내년까지 우분투 16.04를 지원하지 않으므로 우분투 14.04에 없는 모든 종속성을 얻으려면 도커가 필요합니다 = swig3.0 libsystemd-devel.

오늘 회의에 참석하지 못해서 죄송합니다. 직장에서 우리는 오늘 대규모 소프트웨어 출시를 준비 중이므로 사무실을 떠날 수 없습니다. 그러나 잠시 후 나는 이메일에 답장을 보낼 수 있습니다.

2일 전에 travis용 OS X 빌드를 추가하기 시작했습니다. https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
빌드는 여기: https://travis-ci.org/manuelm/libelektra/builds/130898079
여기에서 항목을 엽니다.

• [ ] cryto_openssl 컴파일 실패
• [ ] 바인딩 테스트 실패
• [ ] 자바 없음

누군가 여기에서 내 작업을 맡는다면 기쁩니다. 나는 OS X가 없고 travis가 OSX 시스템 요약을 매우 빠르게 검사하기를 기다리고 있습니다.

re: docker: 예, travis 기본 우분투 버전이 제대로 작동하지 않습니다. cmake도 너무 오래되었습니다.
업로드된 도커 이미지를 가져오는 데 약 3분이 소요됩니다. 더 많은 이미지를 추가하는 것은 쉬운 일이 아닙니다. 따라서 기본 travis Linux 환경에 있는(또는 업데이트 후에 있을 수 있는) 함정을 해결하는 좋은 방법이라고 생각합니다.

libelektra(cmake + make + make test)의 다양한 빌드 및 테스트 단계를 docker(build + run) + travis(before_install, before_script, script)와 통합하는 좋은 방법을 찾지 못했습니다. 명령이 완료된 후 Docker 컨테이너가 종료됩니다. 도커 컨테이너는 폐기해야 하므로 나중에 다시 시작할 수 없습니다. 따라서 로컬 디렉토리를 컨테이너에 마운트하지 않는 한 디스크/컴파일 상태가 사라집니다. 다음 주에도 docker 작업을 계속할 것입니다.

@manuelm 훌륭합니다. 우리가 생각한 것보다 훨씬 더 발전했습니다. PR 및 커밋당 Mac OS X는 정말 훌륭할 것입니다. 많은 사람들이 지금 Mac OS X을 사용하고 있으며 저는 그들을 위한 빌드를 계속해서 깨고 싶지 않습니다. 오늘 회의에서 @mpranj 가 당신의 일을 픽업

아니요, travis 파일은 나중에 수정해야 하기 때문입니다. 그렇지 않으면 OS X만 빌드됩니다. @mpranj 가 내 travis 파일을 사용하고 나머지 OSX 관련 문제를 수정하는 것이 좋습니다. 그런 다음 그의 travis 파일을 가져와 매트릭스 빌드로 변환하고 linux/docker 빌드 + #730(그때까지 사용 가능한 경우)을 통합합니다.

추신: 사용자 이름 간격 저장소에서 트래비스 테스트를 수행하십시오. 많이 밀어주실거에요 :-)

mingw64는 추가된 PR을 기반으로 하며 작동해야 합니다. 지연 돼서 죄송합니다. 오늘은 트래비스에 대해 알아보겠습니다!

PR(Github PR 빌더 사용)의 구문으로 빌드 작업을 트리거할 수 있는 단점이 있습니까?

수정 여부를 테스트할 수 있도록 #745에서 작업을 구성하고 싶지만 대부분의/(모든) 빌드 작업에 적용할 수 있습니다.

편집: 모든 작업을 자동으로 시작하지 않는 것이 좋습니다. 이미 많은 작업이 있습니다.

모든 작업이 문구로 트리거되도록 구성할 수 있다면 좋은 생각이라고 생각합니다. (적어도 elektra-test-bindings의 경우) 작은 단점이 있다고 생각합니다. 빌드할 분기를 입력해야 하며 단순히 "지금 작업 빌드"를 누를 수 없습니다. 그것에 대한 해결책을 찾으면 좋을 것입니다.

그리고 당신은 우리가 오히려 자동 작업을 줄여야 한다는 것에 대해 옳습니다.

사실 아주 간단한 해결책이 있습니다. (env)변수 sha1 를 사용하여 PR을 작성합니다. 매개변수화된 빌드는 기본값이 설정되었는지 여부에 관계없이 값을 묻는 메시지를 표시합니다.

솔루션: 환경 변수 sha1 를 master (jenkins 구성 자체에서)로 설정하고 매개변수화된 빌드를 비활성화합니다. 변수 설정에 이의가 없다면 @markus2330 위에서 언급한 문제를 정확히 해결할 수 있습니다.

이미 설정했으므로 elektra-mergerequests 에서 해당 빌드 버튼을 누르면 빌드 마스터가 시작됩니다.

예, 이것은 매우 좋은 솔루션입니다. 마음에 듭니다. 또한 단일 스위치로 릴리스 분기를 구축할 수 있습니다(향후 필요할 경우). 그때까지 "마스터"는 PR 내에서 실행되지 않는 경우 항상 올바른 선택입니다.

나는 그것이 또한 우리가 이전에 가지고 있던 필터링된 환경 변수의 문제를 해결할 것이라고 생각합니다.

그런 다음 빌드 작업(-mergerequest bulid 작업의 중복 없음)과 새로운 일관된 명명 스키마를 줄이는 방법도 생각할 수 있습니다. (여기에서 제안할 수 있습니다.) 한 가지 미해결 문제가 있을 수 있습니다. 현재 우리는 PR과 마스터 모두에 대해 적용 범위, docu,..를 구축하고 별도의 장소에 복사합니다. 빌드 작업을 병합하는 경우 작업 마스터/PR 작업 내에서 구분하여 적용 범위를 복사하고 다른 위치에 문서화하는 방법이 필요합니다.

나는 이것을 모든 작업에 적용하는 것을 거의 완료했습니다(그러나 서버 _just_는 정말 느려졌습니다).
와일드카드를 빌드하는 작업에는 적용되지 않음 **(doc 및 기타 일부, 그러나 매우 적음)

빌드 작업을 나중에 다시 시작하면(릴리스 시간 제외) 작업하려는 경우 언제든지 빌드 작업을 중지할 수 있습니다. 일반적으로 젠킨스 자체가 머신 속도 저하의 원인입니다. 현재로서는 백업의 rsync가 문제일 수 있지만 시급합니다.

네, 전혀 문제가 없습니다. 완료해야 하지만 마지막으로 몇 가지 확인하겠습니다.

뉴스 @ElektraInitiative/elektradevelopers:

• 언급했듯이 거의 _모든 것_은 PR에서 지금 빌드할 수 있고/또는 빌드 버튼만 누르면 됩니다.
• 트리거 문구는 항상 elektra- 접두사가 없는 작업 이름입니다. (예: elektra-clang: jenkins build clang please) 레거시 이유로 jenkins build please 및 기타 오래된 문구를 변경하지 않았습니다.
• github 빌드 상태 메시지는 항상 정확히 빌드 작업 이름입니다.

고마워, 잘했어! 모든 사람이 현재 어떤 구문이 작동하는지 알 수 있도록 doc/GIT.md를 업데이트하세요.

( @mention 가 단일 메시지에 대해서만 작동하고 모든 사람이 여기에 작성하는 모든 메시지를 읽지는 않기를 바랍니다.)

xcode 6.1 빌드용 Mac OS X이 손상된 것 같습니다.
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

나는 그것을 위해 재 구축을 촉발했지만 일시적인 트래비스 실패처럼 보입니다.

PR을 위한 빌드를 다시 트리거하는 방법을 문서화할 수 있습니까? 나는 그것이 가능한지 몰랐다.

위의 링크를 사용하여 travis-ci.org에서 직접:

나는 이것이 문서 가치가 있는지 의심하지만 그럼에도 불구하고 나는 할 수 있습니다.
git checkout 때문에 빌드가 여전히 작동하지 않습니다. 나는 이것이 우리의 잘못이라고 생각하지 않습니다.

아. 빌드가 트리거/시작되기 전에 병합했다고 생각합니다.
이전에 성공한 다른 PR을 다시 빌드할 때도 손상됩니다.

이것은 다른 무엇보다 트래비스 문제입니다.

알겠습니다. 조사해 주셔서 감사합니다.

@manuelm debian-stable-mm는 도달할 수 없는 것 같습니다(jenkins와 TU 네트워크의 저 모두). 조사해 주시겠습니까?

Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Removed slice User and Session Slice.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Graphical Interface.
Jul 07 15:14:37 <hostname> systemd-nspawn[544]: [  OK  ] Stopped target Multi-User System.
etc..

누군가 컨테이너를 중지한 것 같습니다. 다시 시작했습니다.

btw, 내일 아침부터 8월 1일까지 집을 비울 것입니다. 여전히 이메일로 연락할 수 있지만 잠시 지연될 것으로 예상됩니다.

빠른 수정 감사합니다! 그래서 당신도 다음 회의에는 여기 없을 것 같아요.

네

일부 작업에는 다음과 같은 오류가 있습니다.

Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.

예: http://community.markus-raab.org :8080/job/elektra-icheck/lastFailedBuild/console http://community.markus-raab.org :8080/job/elektra-doc/lastFailedBuild/console

그것은 만드는 동안 젠킨스 업데이트 또는 @KurtMi에 의해 발생할 수 있습니다 kdb_import_man 분기를?

참고 사항: cppcms를 설치해야 합니다.

지점에 대해 죄송합니다. github 페이지에서 직접 PR을 했습니다.

이런 식으로 PR을 만드는 것이 더 쉽습니까? github는 병합 후 분기를 삭제하도록 제안하지 않습니까?

변화가 너무 적어서 게을렀습니다. 아주 작은 수정의 경우 예, 하지만 분명히 분기는 나중에 삭제되지 않습니다. 병합 후 삭제 분기를 보지 못했습니다.

불안정한 빌드가 깨졌다고 생각합니다.

Cloning the remote Git repository
Cloning repository git://github.com/ElektraInitiative/libelektra.git
 > git init /home/jenkins/workspace/workspace/elektra-mergerequests-unstable # timeout=10
Fetching upstream changes from git://github.com/ElektraInitiative/libelektra.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: fatal: The remote end hung up unexpectedly

전체 로그

@KurtMi가 불안정하게 다시 작동하지만(대부분의 빌드에서) Walk 오류는 일부 더 간단한 빌드 작업에서 지속됩니다. 지점이 어딘가에서 여전히 사용 가능한 것 같습니다. 아마도 빌드 서버의 캐시에 있습니까?

 > git -c core.askpass=true fetch --tags --progress git://github.com/ElektraInitiative/libelektra.git +refs/heads/*:refs/remotes/origin/* --depth=1
Seen branch in repository origin/debian
Seen branch in repository origin/kdb_import_man
Seen branch in repository origin/master
Seen 3 remote branches
FATAL: Walk failure.
org.eclipse.jgit.errors.RevWalkException: Walk failure.

@mpranj 소스에 더 많은 스크립트를 추가해야 할 수도 있습니다. 이렇게 하면 모든 빌드 작업에 대해 더 쉽게 업데이트할 수 있습니다. #806에서 우리는 빌드 디렉토리에 공백이 있는 또 다른 버그를 발견했습니다. 그래서 우리는 전역적으로(모든 빌드 작업에 대해) 빌드 디렉토리에 공백을 추가해야 합니다. 몇 가지 유용한 변수(예: export HOME="$WORKSPACE/user space )를 내보내고 다음을 수행하는 jenkins-setup 스크립트를 추가할 수 있으면

mkdir "build space"
cd "build space"

또한 하나의 글로벌 리포지토리를 업데이트하는 빌드 작업을 만들어야 합니다. 개별 작업은 위를 참조하십시오.

글로벌 리포지토리는 확실히 대역폭을 줄이는 데 도움이 될 수 있습니다. 소스 내에서 스크립트를 빌드하는 것도 좋은 생각이 될 수 있습니다. 적어도 git에서 추적할 수는 있을 것입니다.

나는 경로의 공백 팬이 아니지만 확실합니다.

passwd의 빠른 빌드가 깨졌습니까?

빠른 빌드 작업은 귀찮습니다. 모든 빌드에서 kdberrors.h를 제거하고 더 원활하게 작동하는지 확인하려고 합니다. 장기적으로 #730의 @manuelm 제안이 최상의 솔루션입니다. 소스가 어떻게 업데이트되었는지 확인하고 이를 기반으로 적절한 측정을 수행해야 합니다.

#894도 빠른 빌드를 수정한다고 생각합니다. kdberrors.h를 제거하는 행에 주석을 달겠습니다.

일부 작업(예: html 문서 작업)이 손상되었습니다.

@mpranj 볼 시간 있나요?

@markus2330 완료. 나머지 빌드 실패는 빌드 시스템과 관련이 없는 것 같습니다.

@mpranj 감사합니다! 그것을 고치기 위해 무엇을 했습니까? 여기에서 서버 문제를 구축하기 위한 솔루션도 수집하면 유용할 것이라고 생각합니다.

"소스 코드 관리" > "Git"에서 변경했습니다.
"분기 지정자" 값 "**"에서 "${sha1}"로

이것은 우리가 다른 작업에서도 사용하는 것입니다. 이를 통해 버튼(분기 기본값은 마스터) 또는 github PR 빌더(커밋의 sha1)로 빌드를 트리거할 수 있습니다.

ENV 변수 "sha1"을 "master"로 한 번 설정한 것을 기억합니다. 지금은 없는 것 같지만 작업은 잘 작동하므로 무시합시다.

Object Libraries를 더 자주 사용하면 빌드 속도를 훨씬 높일 수 있다고 생각합니다. 많은 개체 파일이 여러 번 컴파일됩니다. 컴파일 플래그가 객체 라이브러리를 사용하는 모든 위치에 대해 동일한지 확인하기만 하면 되지만 이는 쉽게 가능해야 한다고 생각합니다.

그것이 큰 차이를 만들 수 있는 예는 제 생각에 KDB입니다.

@Namoshek 일반적인 빌드 시스템이 아닌 build _server_ 항목만 여기에 게시하십시오. 객체 라이브러리는 이미 플러그인에 사용되지만 다른 변형에 대해서는 그럼에도 불구하고 다른 객체 라이브러리가 필요합니다(다른 컴파일러 플래그로 인해). 그러나 구체적인 제안은 별도의 문제로 보고하십시오(kdb 도구를 의미합니까?).

Jenkins가 2.7로 업그레이드되었으며 모든 플러그인이 업그레이드되었으며 권장 플러그인이 추가되었습니다.

• 파이프라인(설치에 실패한 것 같습니까?)
• GitHub 조직 폴더 플러그인

일부 플러그인 제거:

• 지점 API
• CVS/SVN(더 이상 필수가 아닌 것 같습니다)

또한 모든 에이전트에 ruby-dev가 설치되었습니다.

상단 게시물에 "현재 문제"를 업데이트했습니다. Elektra도 종속성을 설치하지 않고 컴파일하는 것이 중요하므로 종속성이 설치되지 않은 빌드 서버 에이전트(cmake 및 build-essential 제외)로 이를 확인해야 합니다. 그러나 FreeBSD 및 OpenBSD 빌드 에이전트도 중요합니다. ;)

@mpranj elektra-multiconfig-gcc47-cmake-options에 무엇이 문제인지 알고 있습니까? 그들은 "치명적인: 참조는 나무가 아닙니다:" 오류가 도처에 있습니다. 작업 구성에 "sha1"이 있습니까?

multiconfig를 구체적인 컴파일러와 독립적으로 만들었으므로(특정 컴파일러에 대한 다른 빌드 작업이 충분함) 모든 에이전트에서 실행할 수 있어야 합니다.

@markus2330 잘 모르겠습니다 . 나는 아무것도 변경하지 않았고 단지 :

• 마스터에서 수동으로 빌드를 트리거했습니다.
• github에서 빌드를 트리거했습니다.

두 빌드 모두 트리를 확인하고 빌드를 시작할 수 있었습니다.
그래서: 나는 그것을 재현할 수 없습니다.

한 가지 아이디어: Travis는 PR이 있을 때 문제가 있었고 Travis가 복제를 수행하기 전에 이를 병합했습니다. 빌드가 ~3시간 정도 걸리기 때문에 elektra-multiconfig-gcc47-cmake-options 에서도 비슷한 일이 발생했을 수 있습니다.

아티팩트를 doc.libelektra.org에 다시 푸시하면 Jenkins 및 플러그인이 업그레이드되었습니다.

github의 Webhook에서 새 빌드 서버 URL https://build.libelektra.org 를 업데이트했습니다. 그래서 다음 PR이 다시 구축되기를 바랍니다.

Jenkins 집이 거의 가득 찼습니다. 또한 PR을 구축하지 않는 것 같습니다.

Jenkins 집이 거의 가득 찼습니다.

덕분에 사이즈 조절했습니다.

또한 PR을 구축하지 않는 것 같습니다.

여기서 무엇이 잘못될 수 있는지 아십니까? 수동 트리거링이 작동하는 것 같습니까?

doc.libelektra에 문서 게시. org:12025 빌드에 실패했습니다. ssh 서버(build-homepage 에이전트에서)를 다시 시작했는데 다시 작동하는 것 같습니다.

*.libelektra.org용 가상 서버에 연결할 수 없는 것 같습니다. 헤츠너에 신고했습니다.

컨테이너에서 네트워크 연결을 종료한 이유는 libelektra.org가 손상되었기 때문입니다. 자세한 내용은 #1505를 참조하십시오.

스트레치용 git-build-package를 추가할 수 있다면 좋을 것입니다. 스트레치용으로 빌드된 데비안 패키지가 필요한 곳이 점점 더 많아지고 있습니다.

@BernhardDenner 상단 포스트 잘 보셨나요? 쉽게 할 수 있는 일이 있나요? @mpranj 가 향후 빌드 서버 작업을 개선할 때 고려해야 할 사항이 있습니까?

@sanssecours의 요청에 따라 PR에 항상 잘못된 오류가 발생하지 않도록 elektra-mergerequests를 (일시적으로) 비활성화했습니다. 또한 @KurtMi를 추가했습니다

jenkins는 gcc-configure-debian-optimizations 를 빌드하십시오.

@KurtMi 빌드 작업이 수행하는 작업을 변경해야 하는 경우 scripts/configure-debian-optimizations를 수정하기만 하면 됩니다.

@sanssecours는 이제 빌드 서버에도 액세스할 수 있습니다.

ㅋ 어쨌든 다른 작업으로 대체되면 작업을 취소할 수 있습니다(현재 로드가 과중함). 활성 PR에 대한 작업을 중단하지 않도록 주의하십시오. 그렇지 않으면 PR이 녹색이 ​​되지 않습니다. ("jenkins build ... please"라는 문구로 다시 시작하지 않는 한.)

@sanssecours Jenkins가 다시 시작되었습니다(두 번째). 새 플러그인을 설치하는 경우 여기에서 문서화할 수 있습니까? (업데이트를 문서화할 필요는 없습니다.)

재시작 요청도 여기에서 수행할 수 있습니다.

"Quiet period"를 2에서 5로 변경하여 반복적으로 다시 빌드하지 않고 여러 PR을 병합하거나 다른 커밋을 푸시할 수 있는 더 많은 시간을 제공했습니다.

또한 빌드의 시간 초과를 설명하는 문제 #1689를 열었습니다(긴 오류 메시지로 인해 여기에 추가하지 않았습니다).

또한 새 섹션 "사용되지 않는/관련 없는 문제 [이유]:"에서 일부 사용되지 않는 작업을 이동했습니다.

빌드 서버에서 플러그인을 업데이트했습니다. 업데이트를 통해 PR #1698 및 PR #1692의 문제가 해결되기를 바랍니다.

@markus2330 빌드 서버를 다시

Jenkins를 2.73.2에서 2.73.3으로 업그레이드하고 Jenkins를 다시 시작했습니다.

업데이트를 통해 PR #1698 및 PR #1692의 문제가 해결되기를 바랍니다.

이 두 PR과 관련이 없는 일반적인 문제일 수 있습니까? 이제 해결되기를 바랍니다.

JENKINS_HOME 거의 찼나 보네요 😢.

@markus2330 👋

• 홈 디렉토리를 청소하거나 어떻게 할 수 있는지 알려주십시오.
• Jenkins 및 모든 오래된 플러그인을 업데이트하시겠습니까?

핑해줘서 고마워!

플러그인에 "임의 파일 읽기 취약점", 즉 "스크립트 보안 플러그인 1.35"가 있는 것 같습니다.

모든 플러그인을 업그레이드하고 젠킨스를 2.73.3에서 2.89.1로 업그레이드했습니다.

또한 디스크 크기를 20GB에서 50GB로 조정했습니다.

곧 서버를 다시 시작해야 합니다. 라이브러리 업그레이드의 영향을 받을 수 있는 다시 시작되지 않은 프로세스가 있습니다. 현재로서는 안전하지 않을 수 있습니다(하지만 jenkins와 관련이 없음). @BernhardDenner 다시 시작할 수 있습니까? (시작되지 않으면 수정 작업을 수행하십시오)?

이 업그레이드 동안 내가 고장난 것을 보고하는 것을 주저하지 마십시오.

서버에 부하가 20이고 거의 응답하지 않았습니다. "jenkins build all please"에 주의해야 하며 장기적으로 에이전트를 주 서버에서 멀리 옮겨야 합니다.

Jenkins 2.89.2로 업그레이드하고 서버를 다시 시작했습니다. 모든 것이 정상화되면 다시 보고하겠습니다.

"서버 호스트 키가 검증자 콜백에 의해 수락되지 않았습니다"라는 오류와 함께 모든 에이전트의 연결이 이제 끊어진 것 같습니다.

@BernhardDenner 퍼펫 적용이 실행되는 것을 보았는데 현재 설정 작업을 하고 있습니까?

2.89.1 및 2.73.3으로 다운그레이드를 시도했지만 성공하지 못했습니다. 에이전트 연결이 여전히 작동하지 않습니다.

ssh 문제를 해결한 @BernhardDenner 에게 큰 감사를 드립니다.

릴리스 정보를 읽지 않고 Jenkins 업그레이드를 중단해야 합니다. 안정적인 업데이트라도 너무 많은 부분을 깨는 것 같습니다. (다운그레이드해도 되돌릴 수 없습니다!)

빌드 서버에서 주요 병목 현상을 보고해야 합니다.
elektra-multiconfig-gcc47-cmake-options 는 14시간이 걸리고
elektra-multiconfig-gcc-stable 는 4시간 걸립니다.
이것이 새로운 동작인지 확실하지 않고 이러한 작업이 단일 빌드 작업이 아니라는 것을 알고 있지만 이 병목 현상을 간과해서는 안 됩니다.

신고해 주셔서 감사합니다. 아이디어는 이러한 작업의 하위 작업을 ryzen 하드웨어에 배포하는 것이었지만 불행히도 아무도 설정할 시간이 없었습니다. 누군가 관심이 있다면 저에게 연락하십시오.

a7.complang.tuwien.ac.at(ryzen)이 충돌한 것 같습니다. 문제를 보고했습니다. 관리자가 월요일에 컴퓨터를 다시 시작할 것입니다.

일시적으로 증분을 비활성화하고(이상한 오류, #1784 참조) 관리자가 ryzen 서버를 다시 시작한 다음 jenkins를 다시 시작했습니다(Jenkins가 ryzen에 연결할 수 없고 ryzen 빌드의 거대한 백로그가 있었기 때문에).

이제 ryzen이 다시 작동하고 백로그를 생성합니다.

아이디어는 이러한 작업의 하위 작업을 ryzen 하드웨어에 배포하는 것이었습니다.

@markus2330 multiconfig 작업의 구성 매트릭스 설정에 Run each configuration sequentially 라는 옵션이 있다는 것을 알았습니다. 우리가 이것을 선택 해제하여 한 번에 여러 구성 옵션을 빌드하면 자동으로 배포될 수 있습니다. 아니면 이미 시도했습니까?

아뇨 안써봤는데 한번 해보세요

@markus2330 빌드 서버 대기열에서 판단하면 이것이 트릭을 수행하는 것 같습니다. gcc-stable-multiconfig에서 작동한 후 추가로 gcc-stable에 적용하겠습니다.

그러나 나는 ryzen이 그 작업을 처리하지 않는 것 같다는 것을 알아차렸습니다. 태그와 일치하는 작업만 처리하도록 구성되어 있고 multiconfig 빌드가 언뜻 보기에 해당 태그를 적절하게 설정하지 않는 것 같습니다. 따라서 우리는 ryzen이 가능한 모든 것을 실행하도록 하거나 빌드 작업에 더 많은 태그를 설정해야 합니다. ryzen은 태그가 전혀 설정되지 않은 작업을 처리하지 않는 것 같습니다.

gcc-stable-multiconfig에서 작동한 후 추가로 gcc-stable에 적용하겠습니다.

감사합니다!

그러나 나는 ryzen이 그 작업을 처리하지 않는 것 같다는 것을 알아차렸습니다.

아니요, 그렇지 않지만 이미 많은 다른 작업을 실행하고 있습니다. 하지만 v2를 그렇게 만들 수 있을까요?

추가로 gcc-stable에 적용하겠습니다.

완료

하지만 v2를 그렇게 만들 수 있을까요?

나는 v2를 구성했고 지금은 #1806 PR이 병합되기만을 기다리므로 하나보다 더 많은 빌드를 허용할 수 있습니다. SMT도 활용하려면 -j 2와 함께 8코어이기 때문에 8개의 작업이 적합해야 한다고 생각했습니다.

v2가 충돌하거나 다시 시작되는 경우 build-v2 컨테이너를 다시 시작하려면 . 이것은 컨테이너가 이미 빌드된 경우에만 수행할 수 있습니다. 이 지침을 보려면 doc/docker/jenkinsnode/README.md를 따르십시오. 그런 다음 이 명령을 사용하여 컨테이너가 생성되었지만 중지된 후 다시 시작합니다.

docker start build-v2

또한 a7을 통해 v2에서 새 빌드 노드의 ssh 연결을 외부 세계로 전달하기 위해 a7에 다음 ssh 터널을 설정했습니다(도커 컨테이너는 ssh 포트를 v2의 22222에 매핑합니다).

ssh -L 0.0.0.0:22222:localhost:22222 <username>@v2.complang.tuwien.ac.at

이에 더해 도커 컨테이너의 공개 ssh 키는 이미지를 다시 빌드할 때마다 변경되므로 빌드 서버에서도 조정해야 합니다. 컨테이너가 다시 시작되기만 하는 경우에는 필요 하지 않습니다 . 그것을 찾으려면 v2에서 다음을 입력하십시오.

sudo docker exec -it build-v2 bash
# now you should be on the docker machine
cat /etc/ssh/ssh_host_ecdsa_key.pub
> ecdsa-sha2-nistp256 <blablablalb> <root@6b906cc01f23>

처음 두 가지만 복사하므로 키 알고리즘과 키 자체가 ssh 키에 대한 jenkins의 ryzen-v2 구성에 마지막에 이 사용자 정보를 복사하지 마십시오!

v2가 다운되어 관리자에게 알렸습니다. 상당히 이상합니다. a7과 v2는 모두 완전히 새로운 하드웨어이며 사고가 자주 발생합니다.

v2가 돌아온 것 같고 거기에서 빌드 컨테이너를 다시 시작했습니다. 이제 다시 더 빠른 빌드가 가능하기를 바랍니다. 추가적으로 저는 typechecker를 위한 안정적인 하스켈 빌드를 원하기 때문에 "jenkins build all please"에 elektra-haskell을 추가했습니다. 따라서 테스트는 좋은 추가 기능입니다.

또한 여기에 추가로 v2에서도 새로운 병목 현상으로 나타나는 mm 빌드를 처리하는 또 다른 빌드 노드를 만들고 싶다는 메모를 남기고 싶습니다.

마지막으로 @markus2330 포인트 실행 bashism 검사기가 이미 완료된 것 같습니다. 이것은 우리의 일반적인 테스트 중 하나이기 때문입니다. /testscr_check_bashisms.sh .

레이블 debian-jessie-homepage||homepage 및 빌드 에이전트 debian-wheezy-mr 모든 노드는 현재 오프라인 상태입니다. 빌드 에이전트를 다시 시작해도 작동하지 않습니다. SSH 또는 이러한 노드에 대한 물리적 액세스 권한이 있는 사람이 이 문제를 조사할 수 있다면 정말 좋을 것입니다.

가상 서버를 다시 시작했지만 jenkins 내에서 에이전트를 다시 시작해도 "요청에 유효한 빵 부스러기가 포함되지 않았습니다"라는 오류와 함께 작동하지 않았습니다. @BernhardDenner 아이디어가 있습니까?

v2도 다운된 것 같습니다. 그래서 우리는 작동하지 않는 에이전트가 3개 있습니다 😢

v2가 돌아왔지만 왜 항상 다운되는지 궁금합니다. 빌드 프로세스와 관련이 있을까요?

"유효한 부스러기 없음"과 관련하여 v2에서 에이전트를 다시 시작하려고 할 때도 보았지만 단순히 다시 시도했을 때 작동했습니다.

v2가 돌아왔지만 왜 항상 다운되는지 궁금합니다. 빌드 프로세스와 관련이 있을까요?

커널/하드웨어 오류인 것 같습니다(컴퓨터가 멈추면 sysreq도 작동하지 않음). 우리가 사용하면 오류가 발생할 수 있습니다. 컴퓨터는 몇 달 동안 오류 없이 실행되었으며 우리가 사용하기 때문에 이미 세 번 충돌했습니다.

커널을 업그레이드하고 X-서버를 제거했습니다.

"유효한 부스러기 없음"과 관련하여 v2에서 에이전트를 다시 시작하려고 할 때도 보았지만 단순히 다시 시도했을 때 작동했습니다.

감사합니다! 이제 다시 홈페이지 에이전트를 시작할 수 있게 되었습니다.

또한 debian-jessie-minimal 에이전트와 빌드 작업을 비활성화했습니다. 우리는 최소한의 작업을 위해 도커 컨테이너를 만들어야 하며 이것을 작업으로 추가했습니다.

어제 놀랐던 것처럼 커뮤니티 서버가 다운되어 잘못된 ARP 캐시가 우리 IP를 다른 서버로 리디렉션했습니다. 다시 시작한 후 모든 것이 다시 작동했지만 레이드 동기화는 여전히 진행 중입니다. (높은 부하로 인해 너무 느릴 수 있습니다.)

커뮤니티 서버의 로드는 거의 일정한 10입니다. 현재 13.20 11.29 9.35입니다. 커뮤니티 서버에서 직접 실행되는 작업을 줄이고 로드를 v1으로 이동해야 합니다. 자원 봉사자가 있습니까?

Jenkins가 2.89.2에서 2.89.4로 업그레이드되었습니다. 불행히도 Changelog를 보는 쉬운 방법을 찾지 못했습니다( apt-get changelog 는 비공식 패키지이기 때문에 실패합니다). 이 업데이트를 수행하지 않을 이유가 있습니까?

업스트림 변경 로그는 https://jenkins.io/changelog-stable/에 있습니다.
분명히 2.89.4에는 보안 수정 사항이 포함되어 있습니다.

찾아주셔서 감사합니다!

Jenkins 2.89.4로 업그레이드했는데 모든 것이 다시 실행되고 있습니다.

elektrahomepage는 재부팅 후 기본적으로 시작되지 않았으므로 변경했습니다(/etc/vservers/elektrahomepage/apps/init/mark=default).

또한 테스트 도커 빌드 작업을 활성화했습니다.

v2가 다운되었습니다. 다시 :cry:

그러나 적어도 7은 지금 안정되어 있는 것 같습니다.

나는 clang-format-5.0을 7과 스트레치 노드(debian-stretch-mr)에 설치했습니다.

다음 PR을 위해 clang-format-5.0에 따라 다시 포맷하십시오.

https://build.libelektra.org/jenkins/job/elektra-clang-asan/ 이 일시적으로 비활성화되었습니다.

현재 v2를 조사 중입니다. UEFI는 6.6.17부터입니다. 충돌은 항상 주말에 발생하는 것 같습니다. 아마도 그 시간에 더 높은 부하가 있습니까? v2에서 v1 설정을 복제하려고 합니다.

v1과 v2는 동일한 커널로 실행되고 있습니다.

@ e1528532 는 ssh 브리지가 시작되지 않았고 doc/docker/jenkinsnode/README.md의 명령이 "컨텍스트를 준비할 수 없음: Dockerfile 경로의 심볼릭 링크를 평가할 수 없음: lstat /root/Dockerfile: 해당 파일 또는 디렉토리가 없습니다. " 그런 다음 "로컬에서 'buildelektra- stretch:latest ' 이미지를 찾을 수 없습니다". 이것은 현재 v2에 연결할 수 없음을 의미합니다.

@markus2330 작성: 문제를 #1829로 옮겼습니다.

빌드 서버에 대한 최신 업데이트 중 하나가 elektra-gcc-configure-debian-stretch 중단 에 연결할 수 없다고 생각합니다.

stderr: fatal: Unable to look up github.com (port 9418) (Name or service not known)

.

elektra-gcc-configure-debian-stretch 의 문제는 GitHub에 연결할 수 없는 빌드 서버 ryzen 입니다. 그에 따라 빌드 작업의 레이블을 debian 에서 debian-stretch-mr . 이제 빌드 작업 이 다시 작동하는 것 같습니다 .

GitHub에 연결할 수 없는 ryzen

"manged=true"를 사용한 관리자의 NetworkManager 수정이 안정적으로 작동하지 않는 것 같습니다. 다시 시작한 후 "/etc/resolv.conf"는 다시 매달려 있는 심볼릭 링크였습니다. 다시 수정했습니다. GitHub는 ryzen에서 연결할 수 있어야 합니다. rzyen v2는 불행히도 여전히 연결할 수 없습니다(ssh 브리지가 없음).

Elektra 0.8.22가 마침내 출시되었습니다. 웹사이트가 구축되면 #676에 대한 링크를 추가하겠습니다. 웹사이트 구축은 1시간 이상 걸립니다. 홈페이지 빌드를 더 빠른 시스템으로 옮기고 결과 웹사이트만 해당 위치에 복사할 수 있습니다.

http://build.libelektra.org 를 호스팅하는 서버에 대해 뭔가를 했다고 생각합니다 몇 분이 걸립니다.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>502 Proxy Error</title>
</head><body>
<h1>Proxy Error</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
The proxy server could not handle the request <em><a href="/jenkins/">GET&nbsp;/jenkins/</a></em>.<p>
Reason: <strong>Error reading from remote server</strong></p></p>
<hr>
<address>Apache/2.4.10 (Debian) Server at build.libelektra.org Port 443</address>
</body></html>

.

예, 영향을 받는 것은 Jenkins뿐만 아니라 이 서버에서 실행되는 다른 모든 것입니다. 나에게 상황은 종종 용납되지 않습니다. RAM이 너무 적은 것 같습니다. (2GiG 스왑 사용)

Jenkins가 그 이유일 수 있습니다. htop에서 목록을 이끄는 수십 개의 Java 프로세스가 있습니다. 오랫동안 우리는 충분한 RAM을 가지고 있었고 스왑은 거의 사용되지 않았으며 많이 변경되지 않았습니다(Jenkins 업그레이드 및 빌드 작업 수 증가 제외).

커뮤니티 서버를 에이전트로 사용하지 않는 것이 좋습니다. 이를 위해서는 v2가 필요하지만 @e1528532 는 바쁜 것 같습니다. 더 나은 서버를 임대할 수도 있지만 마이그레이션할 시간이 있는 사람이 필요합니다.

@markus2330 빌드 서버를 다시 elektra-todo 와 같은 간단한 작업도 실패합니다.

나는 일요일에 v2를 다시 시작했지만 분명히 이미 다시 다운되었으므로 다른 것을 넣기 전에 먼저 v2를 안정시켜야 합니다.

Jenkins와 v2를 다시 시작했습니다. Jenkins는 다시 원활하게 실행되는 것 같습니다.

@ e1528532 ssh 터널이 여전히 작동하지 않는 것 같습니다. 7을 다시 시작해도 v2에 연결할 수 없습니다.

그래서 우리는 다른 것을 놓을 생각을 하기 전에 먼저 v2를 안정시켜야 합니다.

주요 가동 중지 시간은 ssh 브리지로 인해 발생했습니다. v2에 문제가 있는 경우 일반적으로 하루 이내에 다시 시작되었습니다.
이제 나머지 X 서버를 제거했으므로 이제 v2도 안정되기를 바랍니다. 7의 경우 이것은 트릭처럼 보였습니다(상당한 시간 동안 다시 시작할 필요가 없었습니다). 그러나 v2(ssh 브리지가 필요함)에 로드가 없으면 안정적인지 확실히 알 수 없습니다.

하드웨어(재시작)와 소프트웨어(Jenkins 업그레이드)에 대한 논의를 나누는 것은 어떻습니까?

7과 v2 사이에 네트워크 연결 문제가 있는 것 같습니다. v2가 실행 중이지만 여전히 "호스트에 대한 경로 없음"이 표시됩니다. 오늘은 못 고칠 것 같습니다.

그놈을 제거하면 네트워크 관리자도 제거되기 때문에 v2의 네트워크가 다운되었습니다. 이제 네트워크를 수정하고(/etc/network/interfaces 사용) 최신 BIOS/UEFI로 업그레이드했습니다. 이제 모든 것이 안정되기를 바랍니다.

ㅋ ssh 브리지를 통해 사용할 수 있는 하드웨어가 하나 더 있습니다... (PCS)

ssh 터널이 여전히 작동하지 않는 것 같습니다. 7을 다시 시작해도 v2에 연결할 수 없습니다.

예, 이것은 자동화되지 않았습니다. 이제 나는 모든 것을 돌보았다. 이제 머신이 다시 시작되면 도커 컨테이너가 자동으로 다시 시작됩니다. 적어도 나는 https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode 에 따라 --restart 플래그를 "항상"으로 설정했습니다.

또한 a7과 v2 모두에 암호가 설정되지 않은 "ssh-tunnel-a7-v2"라는 새 사용자를 만들었습니다(따라서 해당 암호 인증을 비활성화함). a7에서 사용자에 대한 ssh 인증서를 만들고 v2의 알려진 호스트에 공개 키를 추가했습니다. 그런 다음 https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service 에 따라 ssh 터널을 systemd 서비스로 자동으로 여는 systemd 서비스를 /etc/systemd/system/ssh-tunnel-a7-v2.service 에 추가했습니다. 따라서 서버가 다시 시작되거나 ssh 연결이 충돌하고 더 이상 나 또는 내 사용자에게 의존하지 않을 때도 작동해야 합니다. 인증서를 사용하기 때문에 연결에 암호를 사용할 필요가 없습니다.

또한 이 새로운 자동 구성이 활성화된 상태에서 v2가 다시 시작됩니다. 바라건대 다음 충돌에서 살아남을 수 있기를 바랍니다(있는 경우). 이론적으로는 그래야 하지만 우리는 보게 될 것입니다.

Jenkins가 ryzen v2 에서 작업을 실행하는 경우 빌드 작업 test-docker 항상 실패합니다.

docker inspect -f . elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-7755b812/script.sh: docker: not found
[Pipeline] sh
[test-docker] Running shell script
+ docker pull elektra-builddep:stretch
/home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: 2: /home/jenkins/workspace/test-docker@tmp/durable-d1c2efc5/script.sh: docker: not found

. ryzen v2 이외의 노드로 작업을 제한하고 싶었지만 test-docker 구성 페이지 에서 이 단계에 대한 옵션이 누락된 것 같습니다. 누군가 이 문제를 살펴보고 해결해 주시겠습니까?

조사해 주셔서 감사합니다! 에이전트에 여러 레이블을 할당할 수 없나요? 그런 다음 ryzen v2에 고유한 레이블을 할당하고 작업을 연결할 수 있습니다.

운 좋게도 곧 빌드 서버에 대한 지원을 받게 됩니다.+1:

에이전트에 여러 레이블을 할당할 수 없나요?

내가 아는 한 상담원에게 여러 레이블을 할당할 수 있습니다.

그런 다음 ryzen v2에 고유한 레이블을 할당하고 작업을 연결할 수 있습니다.

[[1]] 이전에 이미 언급했듯이 "이 프로젝트를 실행할 수 있는 위치 제한" 옵션이 누락된 것 같습니다.

ryzen v2 이외의 노드로 작업을 제한하고 싶었지만 test-docker 구성 페이지 에서 이 단계에 대한 옵션이 누락된 것 같습니다.

.

아, 나는 당신의 말을 "(stable && !ryzenv2)라고 말할 수 있는 부울 표현식을 작성할 방법이 없다"로 오해했으며, 에이전트 제한 옵션이 전혀 없습니다.

아마도 이것은 DSL에 의해 수행될 수 있습니다. Lukas가 무엇을 해야 하는지 알고 있는지 물어보겠습니다.

안녕하세요,

@sanssecours가 언급했듯이 ryzen v2에는 도커가 설치되어 있지 않지만 도커 태그가 있습니다.
테스트 도커를 실행하려면 노드에 도커 태그가 있어야 합니다.

가능한 해결책은 노드에 도커를 설치하거나 젠킨스의 노드에서 태그를 제거하는 것입니다.

가능한 해결책은 노드에 도커를 설치하거나 젠킨스의 노드에서 태그를 제거하는 것입니다.

문제에 대한 솔루션을 제공해 주셔서 감사합니다. 방금 ryzen v2 에서 docker 태그를 제거했습니다. 내가 말할 수있는 한 모든 것이 지금 작동하는 것 같습니다.

'ryzen v2' 노드에 대한 설명을 업데이트하여 실제로 v2에서 실행되는 도커 컨테이너가 '유일한'임을 반영했습니다. 따라서 v2에 도커가 설치되어 있음에도 불구하고 docker를 사용할 수 없었던 이유는 무엇입니까?

또한 더 쉬운 빌드 데이터 시각화를 허용하는 플러그인 을 젠킨스에 추가했습니다(각 빌드를 클릭할 필요가 없음).

v2가 또 다운됐는데 신고했습니다.

v2를 재부팅했지만 에이전트를 다시 연결할 수 없습니다.

적어도 우리는 마침내 충돌 전에 무슨 일이 일어났는지에 대한 오류 메시지를 받았습니다(물론 오류 메시지가 충돌과 관련이 있다는 보장은 없습니다):

watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [docker-containe:789]
...
NMI watchdog: Watchdog detected hard LOCKUP on cpu 14
...

이상하게도 내 재시작 기계가 작동한 것 같으며 ssh 터널과 도커 노드가 모두 다시 시작되었으며 a7.complang.tuwien.ac.at -p 22222에 연결할 수 있습니다. 이는 모든 것이 열려 있어야 함을 의미합니다. 그러나 어떻게 든 jenkins는 어떤 이유로 든 무한한 회전 바퀴를 보여줍니다. 시간 초과도없고 아무 것도 없습니다.

이전과 마찬가지로 수동 ssh 브리지를 시도했습니다. 도커 컨테이너를 다시 한 번 다시 시작했습니다. 그래서 솔직히 나는 오류 메시지 없이 정확히 무엇이 잘못되었는지 잘 모르겠습니다. 내가 찾은 유일한 것은 분명히 비슷한 버그(회전 휠은 있지만 메시지 없음)가 있지만 전체 마스터 젠킨스를 다시 시작하는 것 외에는 해결책이 없는 사람입니다. 노드(시도하지 않음): https://issues.jenkins-ci.org/browse/JENKINS-19465

편집: 제안된 해결 방법 중 하나를 시도했습니다(호스트 이름 구성을 존재하지 않는 것으로 재설정하고 다시 연결한 다음 jenkins는 호스트 이름이 잘못되었음을 깨닫고 실제 호스트 이름으로 다시 변경한 다음 갑자기 더 이상의 번거로움 없이 작동했습니다). 그래서 나는이 오류가 내 재시작 설정 대신에 발생했다고 생각하지만 다음 충돌이 확실해질 때까지 기다릴 수 있습니다 ;)

@markus2330 나는 당신이 이미 이것을 스스로 발견 https://bugzilla.kernel.org/show_bug.cgi?id=196683 , 몇 가지 제안이 있습니다 이에 대한 해결 방법

빌드 서버 ryzen 이 저장소에 연결할 수 없는 것 같습니다.

https://github.com/ElektraInitiative/libelektra.git 에서 가져오지 못했습니다.

.

dns 구성이 다시 매달려 있었습니다. 왜 그런지 완전히 이해하지 못하기 때문에
현재 방식으로 설정합니다. 네임서버 설정만 복원하고
도커 빌드 작업을 다시 시작했습니다.

2018년 3월 12일 17:03에 René Schwaiger [email protected] 은 다음과 같이 썼습니다.

빌드 서버 ryzen이 저장소에 연결할 수 없는 것 같습니다.
https://build.libelektra.org/jenkins/job/test-docker/162/console :

https://github.com/ElektraInitiative/libelektra.git 에서 가져오지 못했습니다.

.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-372363457 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-gcB-XWqDbqbRZfRnfnadYjZN21hks5tdpxLgaJpZM4DIApm
.

나는 그것이 현재 방식으로 설정되는 이유를 완전히 이해하지 못하기 때문에

아무도 이해하지 못할까 두렵습니다. DNS 서버가 잘못 구성되어 적절한 이름 서버 정보를 제공하지 않을 수 있습니다. v2의 경우 네트워크 관리자를 제거했으며 이제 resolv.conf가 안정적인 것 같습니다. 따라서 한 가지 옵션은 7에서도 네트워크 관리자를 제거하는 것입니다. (그리고 /etc/network/interfaces 사용) v2와 a7이 서로 다른 설정을 가질 이유는 없습니다. 단지 관리가 부적절하기 때문입니다.

이상적으로(장기적으로) Puppet을 사용하여 둘 다 관리합니다.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , 이에 대한 몇 가지 제안된 해결 방법이 있습니다.

C6은 비활성화되어야 하지만 조사를 계속할 것입니다.

새 빌드 에이전트 "ryzen v2 docker" 에는 "debian-stable-mm" 처럼 실행되는 D-Bus 데몬이 없는 것 같습니다.

누군가 그것을 설치/시작하거나 어떤 스크립트가 multiconfig-gcc47-cmake-options 빌드를 구성하는지 알려주면 시작되었는지 확인하는 스니펫을 추가할 수 있습니까?

@markus2330 ifupdown과 networkmanager가 모두 활성화되어 있기 때문에 둘 다 서로의 머리카락에 들어가는 것 같습니다. 둘 중 하나를 비활성화하면 확실히 도움이 될 것입니다.

좋아, v2와 일치하도록 a7에서 gnome 및 network-manager를 제거했습니다.

새 빌드 에이전트 "ryzen v2 docker"에는 "debian-stable-mm"처럼 실행되는 D-Bus 데몬이 없는 것 같습니다.

빌드 에이전트는 도커 컨테이너 내에 있으며 @ingwinlu 또는 @e1528532 가 dbus 데몬을 시작하는 데 도움이 되기를 바랍니다.

감사합니다. 상당히 쉬워야 합니다. 다음 명령을 사용하여 도커 컨테이너( docs/docker/Dockerfile 에서 빌드된 Ubuntu 17.10 artful)에서 시작합니다.

mkdir /var/run/dbus # create directory for pidfiles & co
dbus-daemon --system

빌드 서버 ryzen이 다시 저장소에 연결할 수 없습니다 😭.

미안, 내 잘못이야. 네트워크 관리자를 중지하는 것만으로도 시스템을 망가뜨릴 수 있을 것 같습니다.

지금 수정해야 합니다. 추가 문제가 있으면 주저하지 말고 신고해 주세요.

@markus2330 다음 재부팅 시 다시

/etc/network/interfaces 파일을 다시 실행하고 인터페이스 구성을 /etc/network/interfaces.d로 이동했습니다.
네트워크 관리자의 제거와 결합되어 안정적으로 유지되기를 바랍니다.

구성을 검토하고 재부팅을 트리거하여 작동하는지 확인하십시오.

@ingwinlu 수정해주셔서 감사합니다. 재부팅이 잘 되었습니다.

너무 많은 패키지를 제거했다는 것을 알게 되어 Java(openjdk 9 headless 및 default-jre)를 다시 설치했습니다.

@ingwinlu v2 에이전트에서 dbus를 실행시켜 주시겠습니까? 이상적으로는 "/home/armin/buildelektra-stretch/Dockerfile"도 사용자가 아닌 특정 대상으로 재배치하십시오.

@markus2330 빌드 환경을 진행하는 방법에 대한 내 제안은 실제로 현재 dockercontainer-on-v2 노드의 제거를 예상하고 이를 도커 가능 노드로 교체합니다(즉, 더 이상 v2의 도커 컨테이너를 가리키지 않고 v2를 직접 가리킴) .

그런 다음 테스트에 필요한 다양한 환경을 제공하기 위해 저장소에 체크인된 Dockerfile에서 이미지 자체를 빌드하도록 빌드 파이프라인을 설정할 수 있습니다.

dbus 가능 도커 이미지의 롤아웃에 우선순위를 둘 수는 있지만 필요하지 않은 경우 곧 관련이 없는 작업은 하고 싶지 않습니다.

네, 이해가 됩니다!

v2의 장기적인 목표는 다른 도커 컨테이너(Elektra가 아님)와 공유해야 하므로 모든 부분이 다른 도커 컨테이너에 영향을 미치지 않도록 가상화하는 것이 좋습니다. (재귀 도커 또는 Xen?) 동일한 설정을 갖도록 7에 대해 동일한 작업을 수행할 수/해야 합니다.

우리는 계속해서 머신에 직접 액세스할 수 있지만 Jenkins가 관련이 없는 Docker 머신을 죽일 수 있는 위험을 줄여야 합니다.

일부 에이전트의 경우 이미 Puppet 설정이 있습니다. 우회하지 않거나 더 나은 방법으로 이 설정을 7 및 v2로 확장하는 것이 좋습니다. @BernhardDenner 가 이에 대한 자세한 정보를 곧 제공할 수 있기를 바랍니다.

빌드 서버가 다시 다운되었습니다 🙌.

그건 그렇고, 우리는 빌드 서버 상태에 대한 토론을 GitHub 팀 토론으로 이동할 수 있습니다. 이 주제가 이 문제를 구독하는 모든 사람들에게 관심이 없을 수도 있기 때문입니다.

예, 빌드 서버를 포함하여 전체 서버가 다운되었습니다.cry: 그리고 v2도 (독립적으로) 다운되었습니다. v2를 다시 시작하고 UEFI에서 C-States 옵션을 변경했습니다. 하지만 우리 서버에 큰 문제가 있는 것 같습니다. 더 많은 메모리가 있는 더 나은 하드웨어로 교체되기를 바랍니다.

GitHub 팀 토론

GitHub 팀 토론에서 무언가를 작성하면 ElektraDevelopers 모두가 알림을 받지 않습니까? 여기 이 호에서 모든 사람이 구독 여부를 결정할 수 있습니다.

나에게 여전히 열려 있는 질문은 이 문제를 하드웨어 관련 문제와 Jenkins 관련 문제의 두 가지 문제로 나누어야 하는지입니다.

GitHub 팀 토론에서 무언가를 작성하면 ElektraDevelopers 모두가 알림을 받지 않습니까?

내가 말할 수 있는 한 그렇습니다.

여기 이 호에서 모든 사람이 구독 여부를 결정할 수 있습니다.

팀 토론에서도 마찬가지입니다 .

빌드 서버가 다시 작동합니다. 변경된 설정:

• 대기열에 많은 빌드가 있을 때 가비지 수집의 양을 줄이기 위한 xms 및 xmx 설정
• 나는 우리가 scm 폴링을 사용한다는 것을 알았습니다. 나는 서버가 현재 받고 있는 스파이크를 조금 줄이기 위해 한 번에 전 세계적으로 4개의 동시 폴러로 폴러를 조절했습니다.

편집하다:

* webui에 액세스할 때 읽는 여러 소스에 따라 모든 파이프라인에 대해 빌드 수를 30으로 유지하도록 설정합니다. 따라서 많은 수의 이전 빌드가 요청 속도를 늦춥니다.

Jenkins를 버전으로 업데이트하십시오. 2.107.1

• 젠킨스 전쟁 파일 업데이트
• 플러그인 업데이트를 허용하지 않으므로 Use browser for metadata download 플러그인 보안 설정 비활성화
• 사용 가능한 최신 버전으로 플러그인 업데이트

편집 2018-03-18:

• mm에서 실행되는 모든 노드에 두 번째 실행기를 추가했습니다.

* mr에서 실행되는 모든 에이전트의 우선 순위를 낮췄습니다.

마스터는 이제 로드 상태에서 훨씬 더 반응적이어야 합니다. 모든 빌드는 이전의 4h+에서 2h에 더 가까워야 합니다.

편집 2018-03-24:
바쁜 한주, 늦어서 죄송합니다...

• 리포지토리에서 찾은 Jenkinsfile을 실행할 새 작업을 jenkinsserver(elektra-jenkinsfile)에 추가했습니다(존재하면).

편집 2018-03-28:

• 터널 단위 파일을 다시 수정했습니다. 이제 환경 파일을 구문 분석하므로 여러 대상을 가리키도록 조정할 수 있습니다.
• 도커를 실행할 수 있는 슬레이브로 v2 서버 추가
  
  
  
  • v2에 젠킨스 사용자 추가
  
  
  • v2에 openjdk-9 설치
  
  

편집 2018-03-29:

• 젠킨스 마스터에서 ulimit 설정 수정

@ingwinlu 또는 누군가가 이미 여기에 ryzen v2 가 잘못 구성된 것 같습니다.

FATAL: Could not apply tag jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185
hudson.plugins.git.GitException: Command "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" returned status code 128:
stdout: 
stderr: 
*** Please tell me who you are.

Run

  git config --global user.email "[email protected]"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: empty ident name (for <[email protected]>) not allowed

https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console에서 발생했지만 발생 여러 번.

어머 미안합니다. deps가 설치되어 있지 않으며 도커 호스트로만 작동해야 합니다. 추가 플래그를 제거하겠습니다.
// 편집: 완료되어야 합니다. 바라건대 그것으로 충분했다
//EDIT2: 테스트를 실행하는 데 필요한 빌드 이미지를 분명히 찾을 수 없기 때문에 지금은 test-docker 도 비활성화했습니다.

하지만 젠장, 실제로 구축할 수 있는 무언가를 얻으면 빠릅니다.
//EDIT3: docker-prefab 태그가 있는 노드에서만 실행되도록 테스트 도커를 활성화하고 해당 태그를 ryzen에 제공

슬프게도 문제는 원래 예상했던 것보다 더 큰 것 같습니다.

일부 작업에는 노드가 하드코딩되어 있습니다. 일부 태그는 오래되었습니다(jessie 노드에서 안정적). 일부 작업은 이전에 한 번 실행되고 성공적으로 빌드되었기 때문에 올바른 노드가 필요하지 않고 올바른 노드에서만 실행되었습니다.

새로운 노드(ryzen v2 네이티브)의 도입으로 할당이 없어야 했지만 약간 뒤섞였습니다.

모든 것이 다시 원래 위치에서 실행될 때까지 예상치 못한 동작을 예상하십시오.

변경 로그:

• 이름이 변경된 노드, <os>-<hostname>-<buildenv>
• 비활성화됨 elektra-multiconfig-gcc47-cmake-options
  실제로 일정 기간 동안 gcc47 슬레이브에서 실행되지 않았으며 일정에 따라 gcc49 또는 gcc63 빌드가 혼합되어 있습니다. renabled이면 v2의 gcc63 지원 dockercontainer로 이동해야 합니다.
• 수많은 작업에 태그를 다시 지정했습니다(일부 작업이 누락되었을 수 있음).
  
  
  
  • elektra-todo에는 stable 가 필요했지만 모든 안정적인 노드에 실제로 sloccount 설치되어 있는 것은 아닙니다.
  
  
  • 더 많은 유사한 사례
  
  

A7이 다운 된 것 같습니다

waht [email protected] schrieb am Do., 29. März 2018, 21:24:

@ingwinlu https://github.com/ingwinlu 또는
누군가가 이미 이것에 있습니다: ryzen v2가 잘못 구성된 것 같습니다:

치명적: jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185 태그를 적용할 수 없습니다.
hudson.plugins.git.GitException: "git tag -a -f -m Jenkins Build #185 jenkins-BUILD_FULL=ON,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON-185" 명령이 상태 코드 128을 반환했습니다. :
표준 출력:
표준 오류:
* 당신이 누구인지 알려주세요.

운영

git config --global user.email " [email protected] "
git config --global user.name "당신의 이름"

계정의 기본 ID를 설정합니다.
이 리포지토리에서만 ID를 설정하려면 --global을 생략합니다.

치명적: 빈 ID 이름( [email protected]용 )은 허용되지 않습니다.

~에서
https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON ,BUILD_SHARED=ON,BUILD_STATIC=ON,ENABLE_DEBUG=ON,ENABLE_LOGGER=ON/console
그러나 여러 번 발생했습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377344978 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-ifc-Ns9q0wuscPa3t8AMo15A07iks5tjTTcgaJpZM4DIApm
.

작업하시겠습니까? 오늘 재부팅할 수 있습니다. 대안으로 우리 관리자 또는 제가 화요일에 재부팅할 수 있습니다.

너무 번거롭지 않다면. 그렇지 않으면 내 PR 작업을 할 수 없습니다.
주말

markus2330 [email protected] schrieb am Sa., 31. März 2018, 14:33:

작업하시겠습니까? 오늘 재부팅할 수 있습니다. 대안으로 우리의
관리자 또는 화요일에 재부팅할 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

좋아, 다시 시작하고 BIOS/UEFI에서 C6-State도 비활성화했습니다(활성화되어 있음). 나는 또한 gnome/xorg를 제거했습니다(이미 그렇게 했다고 생각합니까?).

ㅋ 화면이 완전히 검어서 원인이 무엇인지 추측할 수 있을 뿐입니다.

다음은 10분 정도마다 7에 나타납니다.

Apr 04 07:14:23 a7 kernel: [Hardware Error]: Corrected error, no action required.
Apr 04 07:14:23 a7 kernel: [Hardware Error]: CPU:0 (17:1:1) MC15_STATUS[Over|CE|MiscV|-|AddrV|-|-|SyndV|-|CECC]: 0xdc
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Error Addr: 0x00000003705a2f00
Apr 04 07:14:23 a7 kernel: [Hardware Error]: IPID: 0x0000009600050f00, Syndrome: 0x0000015c0a400f03
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Extended Error Code: 0
Apr 04 07:14:23 a7 kernel: [Hardware Error]: Unified Memory Controller Error: DRAM ECC error.
Apr 04 07:14:23 a7 kernel: EDAC MC0: 1 CE on mc#0csrow#3channel#0 (csrow:3 channel:0 page:0x700b45 offset:0xf00 grain
Apr 04 07:14:23 a7 kernel: [Hardware Error]: cache level: L3/GEN, tx: GEN, mem-tx: RD
lines 5977-6036/6036 (END)

이것이 7 다운타임과 7 latent에서의 이상한 빌드 동작의 원인일 수 있습니다.

make run_memcheck 를 통해 실행되었기 때문에 elektra-ini-mergerequests 에서 valgrind 섹션을 비활성화했습니다.

이들은 10분 정도마다 7에 나타납니다.

예, 우리는 이미 그들을 보았습니다. 컴퓨터를 구입할 때 누군가 실제로 ECC가 작동하는지 확인했으며 당시에는 그러한 오류가 발생하지 않았습니다. 이러한 오류의 빈도는 시스템 부하에 따라 어떻게 됩니까?

make run_memcheck를 통해 실행되었을 때 elektra-ini-mergerequests에서 비활성화된 valgrind 섹션

정리해주셔서 감사합니다.

다시 '실제' 로그 없이 a7에서 임의 출력(컨테이너 충돌, 빌드 중간 중지, 연결 끊김 등)이 발생합니다. 이미 언급한 메모리 수정만 가능합니다.

감사합니다. 뭔가 많이 잘못된 것 같습니다. 이제 수정할 수 없는 오류도 있습니다.

Apr  5 09:50:40 a7 kernel: [39549.503787] mce: Uncorrected hardware memory error in user-access at 73d6ce880
Apr  5 09:50:40 a7 kernel: [39549.503794] [Hardware Error]: Uncorrected, software restartable error.
Apr  5 09:50:40 a7 kernel: [39549.505882] [Hardware Error]: CPU:2 (17:1:1) MC0_STATUS[-|UE|MiscV|-|AddrV|-|Poison|-|-|UECC]: 0xbc002800000c0135
Apr  5 09:50:40 a7 kernel: [39549.506581] [Hardware Error]: Error Addr: 0x000000073d6ce880
Apr  5 09:50:40 a7 kernel: [39549.507287] [Hardware Error]: IPID: 0x000000b000000000
Apr  5 09:50:40 a7 kernel: [39549.507980] [Hardware Error]: Load Store Unit Extended Error Code: 12
Apr  5 09:50:40 a7 kernel: [39549.508677] [Hardware Error]: Load Store Unit Error: DC data error type 1 (poison consumption).
Apr  5 09:50:40 a7 kernel: [39549.509378] [Hardware Error]: cache level: L1, tx: DATA, mem-tx: DRD
Apr  5 09:50:40 a7 kernel: [39549.510136] Memory failure: 0x73d6ce: Killing java:1470 due to hardware memory corruption
Apr  5 09:50:40 a7 kernel: [39549.510908] Memory failure: 0x73d6ce: recovery action for dirty LRU page: Recovered

다시 7로 간다.

보다 생산적인 측면에서: 저는 젠킨스에 블루오션 프론트엔드를 설치했습니다. 시사

다시 7로 간다.

정말 답답합니다. 컴퓨터를 다시 시작하고 에이전트를 다시 연결했습니다. 내일 관리자에게 RAM을 교체하도록 요청할 것이므로 내일 다운타임이 예상됩니다.

보다 생산적인 측면에서: 저는 젠킨스에 블루오션 프론트엔드를 설치했습니다. 시사

좋아 보인다! 다음 회의에서 우리에게 보여줄 수 있습니까?

우리 관리자는 이미 주말에 있습니다. a7을 재부팅하고 BIOS/UEFI를 공장 기본값으로 재설정하겠습니다. 주말에도 오류가 계속되면 RAM을 교환할 수 있기를 바랍니다.

편집: 실행 중인 빌드 작업이 없으므로 빌드 작업이 취소되지 않았습니다.

편집: 모든 것이 다시 시작되었습니다. 지금까지 메모리 오류가 없습니다.

훨씬 더 나은 찾고 있습니다. 누군가 리누스 기술 팁을 너무 많이 보고 서버를 오버클럭했습니까?

죄송합니다. 한동안 Jenkins를 중단해야 했습니다. 서버에 20개의 로드가 있었고 내가 해야 할 일이 더 이상 가능하지 않았습니다(>1h 대기 시간, 그런 다음 Jenkins를 포기하고 중지했습니다).

시작되지 않은 빌드 작업에도 RAM이 필요할 수 있습니까? (대기열 목록이 매우 깁니다.) 그렇지 않으면 로컬 빌드 작업이 이러한 문제에 가장 적합한 후보입니다. (로컬 빌드 작업 3개 실행 중)

@ingwinlu 이상적으로는 해당 서버에 아무것도 구축하지 않습니다. 또한 서버의 부하에 따라 빌드 작업을 만들 수 있습니다. (로드 > 5로 서버에서 작업을 시작하지 않습니까?).

나는 모든 것을 다시 시작했지만 우리가 그것에 대한 빠른 해결책을 찾기를 바랍니다.

Jenkins 시스템 설정에서 VERSION 및 CMPVERSION을 펌핑했습니다.

@ingwinlu Jenkinsfile 에도 이러한 설정이 있으면 좋을 것입니다.

@markus2330 Jenkinsfile에서 이것을 보관하는 방법에 대한 예는 8de9272051fe903a7df08f0abdf18879701f7ac9를 참조하십시오.

다음 대상에서 make run_memcheck 를 제거했는데, 이는 #1882 덕분에 한동안 실패하고 마침내 빌드 시스템에 표시되었기 때문입니다.

• gcc-configure-debian-stretch-minimal
• gcc-configure-debian-wheezy
• elektra-gcc-i386

노드에서 실행하도록 elektra-gcc-configure-debian-stretch 제한: stretch && !mr

jenkins 마스터를 ver. 2.107.2 업데이트 + 모든 플러그인 업데이트

오늘 모든 빌드 작업에 allowMembersOfWhitelistedOrgsAsAdmin 를 추가하려고 했지만 여전히 빌드 전체(#1863 참조)를 제대로 트리거할 수 없고 일부 작업만 실행되는 것 같습니다.

@markus2330 https://github.com/janinko/ghprb/issues/416#issuecomment -266254688

누군가 부탁해도 될까요?

• 고치다
• 비활성화하거나
• (더 나은) 삭제

elektra-clang-asan 제발 🙏. 현재 모든 테스트 실패에도 불구하고 빌드 작업이 실패합니다.

• testlib_notification
• testshell_markdown_base64
• testshell_markdown_ini
• testshell_markdown_mini
• testshell_markdown_tcl
• testshell_markdown_xerces
• testshell_markdown_tutorial_validation

Travis에서 잘 작동합니다.

그들은 (예를 들어) 다른 clang 버전을 사용하는 것과 동일하게 테스트하지 않습니다...

이 스레드는 버그 보고나 더 긴 토론을 위해 절대 추적할 수 없기 때문에 내가 도달하는 즉시 clang 및 clang-asan에 대한 새로운 문제를 열겠습니다.

그들은 (예를 들어) 다른 clang 버전을 사용하는 것과 동일하게 테스트하지 않습니다...

동의합니다. Travis는 오래된 clang 5.0.0 을 사용하지만 elektra-clang-asan 의 Clang 버전은 고대( 3.8.1 )입니다. 그런 오래된 컴파일러에 대한 ASAN 지원 빌드 작업의 값을 볼 수 없습니다.

"elektra-clang-asan"에서 실패한 "testlib_notification" 테스트를 위해 #1919를 만들었습니다.

모든 mr 에이전트가 비활성화된 상태에서 빌드를 모두 테스트했으며 마스터는 완벽하게 응답했지만 모든 mr 에이전트가 활성화된 빌드는 실제로 일부 빌드 시간이 초과되었습니다. 따라서 #1866은 모든 mr 에이전트를 제거할 수 있다면 확실히 개선될 것입니다.

추가 테스트는 홈페이지 구축 작업일 뿐임을 보여줍니다. 지금은 build all 에서 제거했으므로 명시적으로만 실행됩니다.

컨테이너화된 솔루션으로 대체됩니다.

v2는 최신 BIOS로 다시 온라인 상태가 됩니다.

여기에서 모든 segfault를 보고하십시오(CPU에 버그가 있을 수 있음).

a7이 다운 된 것 같습니까?

2018년 5월 4일 11:10에 markus2330 [email protected]에서 다음과 같이 썼습니다.

v2는 최신 BIOS로 다시 온라인 상태가 됩니다.

여기에서 모든 segfault를 보고하십시오(CPU에 버그가 있을 수 있음).

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-386545292 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-qhlMoQ78eNfpLpzXEBLTcq0pKT5ks5tvBsXgaJpZM4DIApm
.

a7이 최신 BIOS로 다시 시작되었습니다.

다시 a7 다운?

예, 충돌했습니다. 오류 메시지 없이 로그인 프롬프트를 보여주고 어떤 입력(sys-req 포함)에도 전혀 반응하지 않았습니다. 하드 리셋 만 도움이되었습니다.

문제가 무엇인지 알고 계시다면 말씀해 주십시오.

슬프게도 영구 저널이 7에 설정되어 있지 않으므로 로그가 없습니다.

언제 7 및 v2를 다시 사용할 수 있습니까?

오, 나는 그들이 다운되었는지 몰랐습니다. 나는 우리 관리자에게 재부팅을 요청하고 그가 할 수 없다면 약 17:00에 할 것입니다.

편집: 그는 즉시 재설정하겠다고 말했습니다.

편집: 그들은 둘 다 다시 일어납니다.

오늘 수동으로 a7 및 v2를 재부팅했습니다. v2에 더 이상 연결할 수 없는 것 같습니다. 실제로 실행 중인지 확인할 수 있습니까?

// 편집: 두 컴퓨터에서 네트워크 구성을 수정하여 해결됨

분명히 7이 다시 떨어졌습니다.

알겠습니다. 재부팅하겠습니다. 그렇지 않으면 이 릴리스가 완료되지 않습니다.

원인의 표시가 있습니까? 그냥 네트워킹 문제입니까 아니면 컴퓨터가 다시 응답하지 않습니까?

모든 것이 지금 실행 중이어야 합니다.

나는 적절한 순간에 그것을 얻었습니다. 마침내 완전히 얼어 붙을 때까지 몇 가지 로그가있었습니다.

로그는 다음과 같습니다.

INFO: rcu_sched detected stalls on CPUs/tasks:
...
rcu_sched kthread starved for 7770 jiffies
watchdog: BUG soft lockup - CPU#2 stuck for 22s! [docker-gen]
... (many repetitions)
NMI watchdog: Watchdog detected hard LOCKUP on cpu 2

그것은 무엇이든 될 수 있습니다. 결함이 있는 ryzen cpu에서 나쁜 psu로 :(

2018년 5월 12일 14:33에 markus2330 [email protected]에서 다음과 같이 썼습니다.

모든 것이 지금 실행 중이어야 합니다.

방금 적절한 순간에 얻었습니다. 마침내 끝날 때까지 몇 가지 로그가있었습니다.
완전히 동결.

로그는 다음과 같습니다.

정보: rcu_sched가 CPU/작업에서 지연을 감지했습니다.
...
rcu_sched kthread는 7770 jiffies에 굶주림
watchdog: BUG soft lockup - CPU#2가 22초 동안 멈췄습니다! [도커젠]
... (많은 반복)
NMI 워치독: 워치독이 CPU 2에서 하드 잠금을 감지했습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

약 #1993

@ingwinlu 현재 성공하지 못하는 작업을 비활성화하십시오(또는 최소한 기본적으로 또는 "jenkins build all please"로 트리거하지 마십시오). 실제로 모든 것이 괜찮은 PR에서 작업을 실패하지 않는 것이 우선 순위가 높아야 합니다. (상당히 실패한 산은 좋은 상황이 아니었다)

Jenkins 작업으로 인해 실패했다면 작업을 다시 시작하는 것이 좋습니다. :heart: #160에서 그렇게 말하는 것도 괜찮습니다.

새로운 CPU와 함께 v2가 다시 등장했습니다!

스트레스 테스트를 위해 많은 작업을 제출하십시오 :스마일:

a7이 다시 다운된 것 같습니다.

감사합니다. 모든 것이 다시 시작되었습니다.

나는 7을 다시 시작했다.

매시간 7을 재설정하는 회로를 사용하면 가용성이 증가할 가능성이 큽니다.

언제 7을 다시 온라인으로 볼 수 있을까요?

a7이 온라인으로 돌아왔습니다

v2가 다시 온라인 상태가 되었습니다.

v2의 전원 공급 장치는 약 1시간 후에 교체됩니다.

@ingwinlu 에이전트를 비활성화하고 나중에 다시 활성화할 수 있습니까? (현재 작업 중인 경우.)

지금은 v2 에이전트가 비활성화되어 있습니다.

v2가 다시 실행 중입니다. 새로운 전원 공급 장치가 있습니다. 기계를 스트레스 테스트하려면 많은 작업을 제출하십시오.

젠킨스 플러그인을 업데이트했습니다. 결과적으로 재부팅하면 이전 jenkins 노드가 부분적으로 복원되어(이름이 변경되기 전) git 리포지토리가 손상됨에 따라 모든 곳에서 빌드가 손상되었습니다.

영향을 받는 리포지토리를 정리하고 캐시된 도커 컨테이너를 정리했습니다.

7이 다시 다운되어 도커 기반 빌드를 다시 사용할 수 없습니다.

또한 보안 제한을 위반하므로 xunit에 대한 업데이트를 롤백합니다.

a7을 재부팅하고 모든 에이전트를 다시 연결했습니다.

7이 다시 다운되어 docker 빌드를 사용할 수 없습니다.

서버를 재부팅하고 에이전트를 다시 연결했습니다.

7을 교체하는 것이 가장 좋은 방법이라고 생각합니다. #2020 참조

다시 다운된 것 같습니다. 내 최신 커밋은 a7-debian-stretch에 연결할 수 없습니다. java.lang.InterruptedException

@e1528532 여기에 써주셔서 감사합니다! 원하는 경우 #2020에서도 투표할 수 있습니다.

a7을 다시 시작하고 에이전트를 다시 연결했습니다.
주말동안 아무 문제가 없기를 바라겠습니다.

7이 다시 다운되었습니다 :cry: 주말 내내 거의 작동했다는 사실이 놀랍습니다. 이번 주의 가동 시간 기록이 될 수 있습니다. 그럼에도 불구하고 #2020은 많은 코멘트를 받지 못했습니다.

나는 a7(sysctl에 반응)을 다시 시작했고 다른 누군가가 젠킨스를 시작했습니다. 모든 것이 다시 실행되고 있습니다.

a7 방금 또 떨어졌습니다.

정보 감사합니다! a7을 다시 시작하고 에이전트를 다시 연결했습니다.

"debian-jessie-minimal" 에이전트가 있다는 것이 말이 됩니까? Docker에 통합되면 안전하게 제거 할 수 있다고 생각합니다. (그리고 이미 그런 것 같다)

편집하다:
https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log에서
및 https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
경고가 있습니다:

WARNING: LinkageError while performing UserRequest:hudson.Launcher$RemoteLauncher$KillTask<strong i="13">@544b40e</strong>
java.lang.LinkageError
    at hudson.util.ProcessTree$UnixReflection.<clinit>(ProcessTree.java:710)
    ...
Caused by: java.lang.ClassNotFoundException: Classloading from system classloader disabled
    at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch4(RemoteClassLoader.java:854)

나쁜 소식. v2도 다운되었습니다.

편집: 하지만 ssh를 통해 연결할 수 있는 것 같습니다....
EDIT2: v2에서 재부팅했지만 이제 더 이상 연결할 수 없습니다. 그래도 a7에서 핑은 가능...

EDIT3: 이제 a7도 다운되었습니다.

신고해 주셔서 감사합니다! a7 및 v2를 재부팅했습니다. #2020을 재고해야 합니다.

v2가 다시 다운되었다고 생각합니다.

v2-debian-stretch에 연결할 수 없음: java.lang.InterruptedException

v2에서는 모든 것이 괜찮았지만 7은 다시 다운되었습니다. 이제 모든 상담원이 다시 온라인 상태가 되었습니다.

v2가 다시 반쯤 응답하지 않는 것 같습니다. a7에서 ping할 수 있지만 ssh 작업은 전혀 없습니다. 증상만으로 btrfs 문제여야 합니다. 주말에 집에 가기 전에 모든 것을 재부팅할 수 있습니까?

@ingwinlu 감사합니다. @waht 와 v2를 성공적으로 재부팅했지만 에이전트를 연결할 수 없습니다(" 연결이 거부되었습니다(연결이 거부됨)"). 여기에 무엇이 잘못되었는지 아십니까? (대화형 ssh 로그인 작동)

ssh는 브리지를 통해 연결하지 않을 때만 작동했습니다.

브리징 서비스를 다시 시작한 후 연결을 설정할 수 있습니다.

ssh-tunnel이 이상한 정의되지 않은 상태로 끝나고 스스로를 죽이지 않은 것 같습니다. 왜 스스로 죽이지 않았는지 확실하지 않습니다(serveraliveinterval이 켜져 있음).

또한 fs가 손상되고 모든 빌드 작업이 실패했기 때문에 v2의 모든 작업 공간을 수동으로 정리해야 했습니다.

a7이 다운된 것 같습니다. 월요일 이전에 재부팅할 수 있을지 모르겠습니다.

a7과 v2를 다시 시작했습니다. (v2는 v2에 대한 ssh 브리지를 생성할 수 없다는 오류 메시지가 7에 있었기 때문에 v2를 다시 시작한 후에도 동일한 오류 메시지가 발생했습니다. 그럼에도 불구하고 ssh 브리지가 작동하는 것 같습니다. 아마도 일부 종속성(네트워크?)이 7의 부팅 스크립트?)

a7의 부팅 스크립트에 일부 종속성(네트워크?)이 누락되었을 수 있습니다.

아니요.

v2에 대한 ssh 브리지를 만들 수 없습니다.

나는 이 동작이 v2 커널이 응답하지 않기 시작할 때 발생한다고 생각합니다(따라서 들어오는 네트워크 연결을 설정할 수 없음). 과거에 v2에서 btrfs 오류를 나타내는 로그를 언급했습니다.

나중에 CPU를 교체하기 위해 종료를 위해 빌드 서버를 준비합니다.

a7 및 v2가 다시 돌아왔습니다(새 CPU가 있는 a7, 루트 파일 시스템이 확인된 v2)

하루 동안 유지되는 동안(일관된 buildign으로) 7이 다시 하락한 것 같습니다.

네, 내일 아침에 다시 시작하겠습니다.

#2020에 대해 다시 논의해야 합니다.

나는 7을 다시 시작했다. 다시 CPU가 멈췄습니다.

a7이 또 떨어졌다.

감사합니다 다시 시작했습니다. 모든 에이전트가 다시 온라인 상태가 됩니다.

일부 데비안 노드가 다운된 것 같으므로 일부 PRS는 이미 테스트 실행이 시작되기를 오랫동안 기다리고 있습니다. 의도한 것입니까?

일부 데비안 노드가 다운된 것 같으므로 일부 PRS는 이미 테스트 실행이 시작되기를 오랫동안 기다리고 있습니다. 의도한 것입니까?

mm-debian-unstable 노드에서 업그레이드하는 동안 시스템이 응답하지 않아 그 이후로 연결할 수 없습니다. 소유자가 우리의 이메일에 응답하지 않기 때문에 아마도 영원히 사라질 것입니다.

많은 양의 빌드 작업을 새 시스템으로 이식했지만 이미 누락된 작업은 현재 대기열에 있는 작업입니다.

영향을 받는 작업을 비활성화하고 문서에서 교체 + 제거로 표시했습니다.

@ingwinlu 처리 해주셔서 감사합니다!

누군가가 리졸버에서 작업하고 싶다면 xdg 테스트를 읽는 것이 매우 중요합니다. 여기 맨 위 포스트에 추가했습니다. 위의 체크리스트에서 이미 달성한 것을 업데이트할 수 있습니까?

이번에는 v2가 행운의 승자입니다.

@markus2330 상단 포스트를 정리했습니다.

정리해주셔서 감사합니다! 내일 아침에 v2(아마도 7, 보자)를 재부팅하겠습니다.

나는 그것을 재부팅했다. 아무런 반응도 메시지도 없었다. #2020 참조

a7 및 v2를 재부팅하십시오.

나는 a7을 재부팅했다. v2에서 문제를 찾지 못했습니다. 어쨌든 재부팅해야 합니까?

i7은 현재 192.168.173.96에서 사용할 수 있습니다.

머신에 ssh-tunnel-a7-v2 사용자를 생성하거나 저를 위한 계정을 생성해야 합니다.

libelektra 빌드 작업에 도움이 되는 추가 빌드 슬레이브 i7-debian-stretch 를 추가했습니다.

더 이상 빌드 작업이 예약되어 있지 않으므로 v2-docker-buildelektra-stretch (offline) 입니다. 에이전트를 노출한 7의 ssh 브리지도 비활성화되었습니다.

안녕하세요 @ingwinlu ,
지난 회의에서 논의한 것처럼 액세스 포인트가 필요합니다.
이메일로 정보를 보내 주시겠습니까? 내 이메일은 AUTHORS.md에 있습니다.
ㅋ 이메일을 찾을 수 없습니다. 이 파일에 자신을 추가해야 합니다.

v2 빌드 서버는 벤치마크를 실행하는 동안 31.07 09:00까지 오프라인 상태가 됩니다. 더 긴 빌드 시간이 예상됩니다.

불편을 드려 죄송합니다.

//편집: 다운타임 2시간 연장

이제 확장도 통과 된 것 같습니다. 점심 식사 후(약 13:00) 빠른 빌드를 다시 사용하는 것이 좋습니다. :웃다:

mm-debian-unstable이 업그레이드되어 다시 온라인 상태가 되었습니다. 다시 활성화하고 서버에 고정할 수 있는 작업이 있습니까?

i7의 디스크가 꽉 찬 것 같습니다. 내 작업은 No space left on device 실패합니다( Job and Job )

그런데 새 빌드 인터페이스(dockerization 및 jenkinsfile)가 정말 마음에 듭니다. 빌드 오류를 재현하는 데 매우 유용합니다.

신고해 주셔서 감사합니다!

불행히도 크기 조정은 다시 시작해야 하며(다른 루트 파일을 확장하기 전에 rootfs를 더 작게 만들어야 함) 20G만 가져옵니다. Jenkins 빌드 폴더를 제거했지만 크기가 작았으므로 여전히 99%입니다.

따라서 _docker를 정리하면 더 효과적입니다.
@ingwinlu 는 _docker/overlay2가 모두 거대한 것 같습니다. 이 모든 것들이 왜 거기에 수집되었는지 아십니까?

docker system prune -fa 청소된 도커 아티팩트를 강제 실행합니다. 이것
도커 이미지에 사용된 약 190GB의 공간을 정리했습니다.

2018년 8월 13일 월요일 07:54에 markus2330 [email protected]에서 다음과 같이 썼습니다.

신고해 주셔서 감사합니다!

불행히도 크기를 조정하려면 다시 시작해야 합니다(rootfs를 만들어야 합니다.
다른 하나가 확장될 수 있기 전에 더 작음) 20G만 가져올 것입니다. NS
Jenkins 빌드 폴더를 제거했지만 크기가 작았으므로 여전히
99%.

따라서 _docker를 정리하면 더 효과적입니다.
@ingwinlu https://github.com/ingwinlu 는 둘 다 _docker/overlay2처럼 보입니다.
거대하다. 이 모든 것들이 왜 거기에 수집되었는지 아십니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412415127 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-oK9dSc27dbXOwgSq4xSWa4IXwiUks5uQRSwgaJpZM4DIApm
.

감사합니다!

이것을 libelektra-daily 또는 cronjob에 넣을 수 있습니까?

Daily는 비슷하지만 덜 공격적입니다. 다른 것을 취해야 할 것입니다
내가 비엔나에 돌아올 때 보세요.

markus2330 [email protected] schrieb am Mo., 2018년 8월 13일, 09:22:

감사합니다!

이것을 libelektra-daily 또는 cronjob에 넣을 수 있습니까?

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRIIC7Mhks5uQSkzgaJpZM4DIApm
.

아침에 빌드 서버가 다운된 것을 눈치 챘을 수도 있습니다. 전원 공급 장치가 손상되어 현재 교체되었습니다.

또한 a7 또는 v2는 다음 주에 짧은 기간 동안 벤치마크를 위해 오프라인 상태가 될 수 있습니다. anton이 벤치마크를 시작하면 오프라인 메시지 "benchmark"가 표시됩니다. 컴퓨터가 너무 오랫동안(예: 하루 이상) 오프라인 상태인 경우 당사에 문의하십시오. (그런 다음 다시 온라인으로 전환하는 것을 잊었을 수 있습니다.)

sid 이미지 문제를 해결했습니다.

testkdb_allplugins debian-unstable-full-clang 테스트 동안 sid 이미지에서 segfault가 발생했지만 v2에서 실행될 때만 해당됩니다. 사용 가능한 최신 패키지를 사용하도록 이미지를 수동으로 업데이트하고 레지스트리에 푸시했습니다.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ 통과했지만 계속 주시할 것입니다.

이 문제는 #2216 및 #2215( @mpranj @sanssecours)에서 언급되었습니다.

도커 레지스트리에 대한 공개 액세스를 구현했습니다. 액세스 방법에 대한 문서는 여기 를 참조

예상대로 작동하지 않는 것이 있으면 알려주십시오.

//EDIT 로그인은 성공해도 푸시가 안 되는 것 같습니다.
//EDIT2 공개 액세스가 다시 비활성화됩니다. https://github.com/moby/moby/issues/18569. 시스템 구축을 위한 기능 복원
//EDIT3: 공개 저장소가 다시 hub-public.libelektra.org에 있습니다.

Anton은 다음 주 화요일 또는 수요일(선택 가능)에 하이퍼스레딩이 비활성화된 컴퓨터의 메인보드를 교체하기를 원합니다. 이 이틀 중 어느 날 빌드 서버가 필요한 사람이 있습니까?

도커 레지스트리를 다시 시작하고 수동으로 정리를 실행했습니다. 웹사이트 이미지의 빌드 문제가 해결되었기를 바랍니다.

@ingwinlu 유지 보수 작업에 감사드립니다!

불행히도 WebUI 단계는 321 또는 320 과 같이 상당히 안정적으로 실패합니다(더 일찍 실패했지만 WebUI를 가져올 때도 실패했습니까?).

나는 마스터에서 작업을 취소하는 것이 나쁜 생각이라고 점점 더 확신합니다. 빌드가 취소되거나 네트워크 문제로 인해 실패하기 때문에 마스터에서 성공한 빌드가 거의 없습니다. 커밋 히스토리에서 어떤 일이 일어났는지 말하기는 어렵습니다. 어느 쪽이든 단순히 실패로 표시되기 때문입니다.

해결 방법으로 c3b59ecef95287ffc33b094b37e03d0ec6b5710f에서 신뢰할 수 없는 단계를 비활성화했지만 곧 다시 활성화할 수 있기를 바랍니다.

a7-debian-stretch 여전히 벤치마크에 대해 오프라인이어야 합니까? (2019년 2월 21일 오전 10:47:56 이후 오프라인 상태)

신고해 주셔서 감사합니다! Anton이 재활성화하는 것을 잊은 것 같습니다. 노드를 다시 활성화하고 이전 노드도 제거했습니다(아직 실행 중인 mm 제외).

아침에 우리 서버의 다운타임이 있었습니다. 모든 것이 다시 실행되지만 하드웨어를 교환하겠다는 제안을 받았습니다. 따라서 오늘 약 1시간의 또 다른 가동 중지 시간이 있을 것입니다.

서버가 다시 작동합니다. 불행히도 우리는 동일한 하드웨어를 가지고 있습니다. 누군가가 설치/설정할 시간이 있으면 하드웨어를 업그레이드할 수 있습니다.

Jenkins 빌드가 상당히 느린 것 같습니다(전체 빌드의 경우 여러 시간). 내가 아는 한 a7-debian-stretch 및 i7-debian 만 테스트를 실행하고 다른 모든 노드는 유휴 상태입니다. 이것은 예상된 동작입니까?

이 문제를 신고해 주셔서 감사합니다!

아니요, 이것은 예상된 동작이 아닙니다. v2가 다운된 것 같습니다. 최대한 빨리 재부팅하겠습니다.

이제 v2가 다시 시작되어야 합니다.

v2가 다운되었고 월요일까지 이 상태가 유지될 것 같습니다. 그때까지는 빌드가 매우 느릴 것입니다.

v2가 다시 새로운 메인보드로 돌아왔습니다.

#2852를 피하기 위해 3개의 빌드 에이전트(i7, v2, a7, 순서대로)를 모두 Buster로 업그레이드합니다.

다운타임을 최대한 줄이도록 노력하겠습니다. 빌드 작업이 실패할 수 있습니다. 다시 시작하십시오(에이전트가 다시 가동된 후).

i7-debian-buster, 이전 i7-debian-stretch가 다시 온라인 상태입니다.

v2는 다음입니다

v2-debian-buster 및 a7-debian buster도 다시 온라인 상태입니다.

모든 것이 다시 작동하는지 확인하기 위해 마스터에서 이전에 성공한 빌드 작업을 다시 시작했습니다.
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

또한 버스터 빌드 작업을 활성화하기 위해 PR https://github.com/ElektraInitiative/libelektra/pull/2876 을 추가했습니다.

v2가 다운된 것 같습니다(ssh 연결도 실패함). 불행히도 저는 비엔나에 있지 않습니다. 나는 우리 시스템 관리자가 내일 그것을 고칠 수 있기를 바랍니다.

a7도 이제 다운되었으며 i7과 함께 (7을 통해 브리지를 통해 연결됨).

따라서 현재 빌드를 수행할 수 없습니다. 관리자에게 연락했습니다.

모든 서버가 다시 작동합니다. 새 커밋을 푸시하거나 PR에 대한 설명으로 "jenkins build libelektra please"를 작성하여 빌드를 다시 시작하십시오.

기술 노트: "watchdog bug soft lockup"으로 인해 7이 다운되었습니다. "nomodeset nmi_watchdog=0"을 추가하려고 했습니다. 그들이 이미 예전처럼 불안정하지 않기를 바랍니다.

a7(또한 v2 및 i7은 7을 통해 브리지를 통해 연결되어 있기 때문에)이 다운되었습니다. 우리 관리자에게 연락했습니다. 대기열이 길어질 수 있으므로 지금 빌드를 시작하지 마십시오.

a7이 다시 온라인 상태가 되었습니다(이미 어제), v2는 영향을 받지 않았습니다.

빌드 서버 상태 페이지에 따르면 서버:

• a7-debian-buster ,
• i7-debian-buster ,
• v2-debian-buster

다운 Jenkins 데이터 디렉토리도 꽤 꽉 찬 것 같습니다. 그리고 우리가 그것에 있는 동안: Jenkins와 플러그인을 업그레이드할 수 있다면 좋을 것입니다. 저는 이러한 문제를 해결하는 데 관심이 있습니다. 그러나 두 가지 문제가 있습니다.

1. 저는 서버 관리에 대한 경험이 많지 않습니다.
2. 기계가 상당히 불안정해 보이기 때문에 기계에 물리적으로 접근해야 할 것입니다.

a7은 i7 및 v2에 대한 브리지이므로 a7이 다운되면 i7 및 v2에 대해 알 수 없습니다.

액세스는 문제가 되지 않습니다. 제가 드릴 수 있습니다. 그러나 Jenkins를 업그레이드하는 것은 일반적으로 Jenkins를 재구성하고(잠시 이후로 업그레이드하지 않은 만큼 많은 릴리스 노트에 따라) Jenkinsfile을 수정해야 하므로(플러그인의 API 변경 사항에 따라) 대규모 작업이라는 점을 알아야 합니다. ). 액세스를 원하시면 저에게 이메일을 보내주십시오.

a7(및 기타 모든 항목)이 다시 작동합니다.

a7이 다시 다운되어 관리자에게 문의했습니다.

기술 노트: "watchdog bug soft lockup"으로 인해 7이 다운되었습니다.

빠른 검색은 이것이 BIOS 문제일 수 있음을 나타냅니다. 사용 가능한 BIOS 업데이트가 있는지 확인한 사람이 있습니까?

a7은 i7 및 v2에 대한 브리지이므로 a7이 다운되면 i7 및 v2에 대해 알 수 없습니다.

나쁜 디자인인 것 같습니다. 방법이 없나요?

빠른 검색은 이것이 BIOS 문제일 수 있음을 나타냅니다. 사용 가능한 BIOS 업데이트가 있는지 확인한 사람이 있습니까?

새 BIOS를 설치하고 CPU를 교체하고 커널을 업그레이드했습니다(위의 메시지 참조). 그 이후로 시스템은 안정적이었습니다. 이제 Debian buster로 업그레이드한 후 다시 불안정합니다.

그럼에도 불구하고 나는 관리자에게 새로운 BIOS가 있는지 물었습니다.

나쁜 디자인인 것 같습니다. 방법이 없나요?

i7 및 v2는 IPv4 주소가 충분하지 않아 사설망에 있습니다. 나는 우리 관리자에게 IPv6 설정이 가능한지 물었습니다.

나는 우리 관리자에게 IPv6 설정이 가능한지 물었습니다.

IPv6은 실제로 필요하지 않으며 다른 안정적인 서버를 브리지로 사용하는 것으로 충분합니다.

대부분 v2는 7만큼 불안정합니다(충돌이 한 번만 발생했지만 a7이 죽으면 즉시 v2의 부하가 걸리기 때문에 이것은 많은 것을 말하지 않습니다). i7을 브리지로 사용할 수 있습니다. 그러나 v2와 7이 다운되면 i7도 별로 쓸모가 없어 빌드 작업을 완료하는 데 많은 시간이 걸릴 것입니다. 또한 i7에는 도커 레지스트리를 위한 공간이 충분하지 않습니다.

따라서 이 변경은 적은 이득으로 많은 노력을 기울일 것입니다.

7과 v2의 실제 문제를 해결하는 것이 훨씬 더 유망합니다.

또한 i7에는 도커 레지스트리를 위한 공간이 충분하지 않습니다.

이 경우 유일한 해결책은 7을 수정하는 것입니다.

불행히도 7이 다시 다운되었습니다.cry:

이전 커널로 부팅을 시도했지만 도움이 되지 않았습니다.

BIOS의 경우 다른 버전을 사용할 수 있지만 릴리스 노트에 따르면 이 문제를 해결할 수 있는 희망이 거의 없으며 더 나빠지면 다시 다운그레이드할 방법이 없습니다...

7용 BIOS가 현재 업그레이드되었습니다. 또한 백포트에서 최신 커널을 사용하려고 합니다.

7은 곧 다시 올라올 것입니다.

새로운 BIOS는 도움이 되지 않았고, 이제 7은 몇 분 안에 충돌했습니다.

a7이 다시 다운되어 관리자에게 문의했습니다. 백포트의 최신 커널은 다음 재부팅 시 시도됩니다.

a7은 5.2 커널과 함께 다시 시작되었습니다.

또 터진거 같은데...

여전히 동일한 오류 메시지가 표시됩니까? 아니면 최소한 약간의 변경 사항이 있습니까?

예, 다시 a7 다운, 관리자에게보고했습니다. 그는 다시 시작할 때 메시지에 대해 알려줄 것입니다.

다른 아이디어가 있습니까? (우리는 이미 BIOS와 커널을 업그레이드했습니다.)

일부 출처에서는 nouveau 그래픽 드라이버에 문제가 있으며 nouveau.modeset=0 시도해야 한다고 제안합니다(어쨌든 이것은 nomodeset 와 다릅니다). 또한 BIOS에서 "C-states"를 비활성화하는 것이 좋습니다.

예, 다시 a7 다운, 관리자에게보고했습니다. 그는 다시 시작할 때 메시지에 대해 알려줄 것입니다.

다른 아이디어가 있습니까? (우리는 이미 BIOS와 커널을 업그레이드했습니다.)

시스템에 '실제' 로드가 있을 때만 발생하는지 확인하기 위해 a7을 젠킨스 슬레이브로 비활성화할 수 있습니다.

@ingwinlu 감사합니다, 좋은 생각입니다. 나는 이제 하나의 빌드 작업으로 a7을 줄였습니다(2개였습니다). 주말 동안(관리자가 사무실을 떠난 후) 에이전트를 완전히 비활성화합니다.

@kodebach : 감사합니다. 정보를 관리자에게 전달하겠습니다.

언제 7이 다시 올라올지 타임라인이 있나요?

a7은 하이퍼스레딩이 꺼지고 동시 빌드 작업이 하나만 있는 상태로 다시 작동합니다.

alpine 및 ubuntu-xenial 빌드를 Cirrus로 이동하여 alpine 의 부하를 줄일 수도 있습니다. 둘 다 단순한 "빌드 및 테스트" 실행입니다. 그들은 보도 범위와 같은 특별한 일을 하지 않습니다.

Cirrus는 사용자당 8개의 동시 Linux 빌드를 허용합니다 . 현재 linkchecker 빌드는 Cirrus의 유일한 Linux 빌드입니다.

사실 ubuntu-xenial 는 우리의 Travis 빌드가 Ubuntu Xenial에서 실행되기 때문에 약간 중복됩니다.

팁에 감사하지만 Jenkins에서 Linux 빌드를 오프로드할 계획은 없습니다. 반대로 @Mistreated 는 Jenkins 인프라를 더욱 최신 상태로 유용하게 개선하기 위해

1. 우리는 완전히 우리 통제하에 있습니다
2. 쉽게 확장할 수 있습니다(빌드 에이전트에는 Java+Docker만 필요함)
3. Jenkinsfile은 매우 깔끔하고 (대부분의 경우) 매우 쉽게 확장 가능합니다.

그러나 물론 모든 사람이 Cirrus(또는 무료로 제공되는 다른 추가 빌드 시스템, #1540 참조)를 확장할 수도 있습니다.

하이퍼스레딩을 비활성화하고 a7에서 1개의 동시 작업으로 제한하는 것에 대응하기 위한 임시 솔루션이었습니다.

a7은 작은 부분(약 2/5)만 만들기 때문에 절반으로 줄이는 것이 거의 눈에 띄지 않을 것입니다. 아니면 지금 특별한 문제가 있습니까? (물론 현재로서는 다운타임으로 많은 작업을 따라잡는데 시간이 걸립니다.)

a7은 작은 부분만 만듭니다(약 2/5).

2/5는 40%입니다. 나는 그것이 작은 부분이라고 생각하지 않을 것입니다.

아니면 지금 특별한 문제가 있습니까?

아니, 실제로는 이전보다 더 잘 작동하는 것 같습니다.

죄송합니다. 약 2/6을 의미했습니다(1/6은 i7, 3/6은 v2). 그리고 이 부분은 제거되지 않고 축소됩니다.

아니, 실제로는 이전보다 더 잘 작동하는 것 같습니다.

완벽한!

a7 또 다운된듯 😭 .

감사합니다! 나는 그것을보고했다.

앞으로는 먼저 발견한 사람이 직접 신고할 수 있다면 좋을 것입니다.

complang.tuwien.ac.at의 허버트

"a7 ist leider nicht erreichbar"라고 말하는 것으로 충분합니다.

그런 다음 여기에도 보고하여 Herbert가 여러 이메일을 받지 않도록 합니다.

확실히 Jenkins 마스터 서버가 그러한 이메일을 자동으로 보내고 이 GitHub 문제에 게시하도록 하는 방법이 있습니다. 그런 간단한 작업을 위한 Jenkins 플러그인이 없었다면 매우 이상했을 것입니다...

예, https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin이 있지만 그것이 우리가 원하는 것을 정확히 수행하는지 확신할 수 없습니다. 누군가가 고의로 상담원을 끄면 이메일을 보낼 수도 있습니다. 그리고 개인 이메일은 관리자가 더 빨리 처리할 가능성이 훨씬 더 높습니다.

우리가 무언가를 자동화하면 연결할 수 없는 경우 PC를 직접 재부팅합니다(어떤 종류의 감시 장치가 내장되어 있을지도?)

a7이 다시 시작되었고 "전역 C-상태 제어"가 비활성화되었습니다.

그러나 빌드 에이전트로 온라인이 아닙니다.

로드 없이도 충돌하는지 봅시다. v2 및 i7이 다시 작동합니다.

관리자(Herbert)는 내일 사용할 수 없으므로 지금은 빌드 에이전트로 7을 남겨둡니다.

내 계획(이전에 항의 또는 7 충돌이 없는 경우)은 내일 빌드 에이전트를 켜는 것입니다. 7이 다시 충돌하면 Herbert는 금요일에 a7을 다시 시작할 수 있습니다. 괜찮아?

대기열이 너무 길지 않다면 7의 빌드 에이전트를 좀 더 오래 비활성화 상태로 유지해야 한다고 생각합니다. 마지막 충돌은 3일 후에 발생했습니다. 내일 활성화하면 그 전에 충돌하지 않는 한 빌드 에이전트가 충돌을 일으켰는지 여부를 알 수 없습니다.

좋아, 그럼 큐 크기가 어떻게 생겼는지 보자.

"글로벌 C-State 제어"가 마침내 문제를 해결하고 테스트하기 위해 높은 부하가 필요하다고 생각합니다.

대기열이 매우 길었고 웹 사이트 배포에 7이 필요하기 때문에 마스터 빌드가 모두 중단되었습니다.

그래서 7 에이전트를 다시 시작했습니다.

기본 빌드 서버의 디스크 공간이 부족하여 최근 Jenkins 빌드 작업 중 일부가 취소되었습니다. 오래된 빌드 작업의 로그를 제거하여 공간을 확보했습니다. 새 빌드 작업의 일부 로그 파일도 제거했을 수 있습니다. 경우에 따라 최신 커밋에 대한 Jenkins 빌드가 실패했을 수 있으며 이제 404 오류와 관련된 일부 메시지만 표시됩니다. 그럴 땐 그냥 아무거나 해주세요

• Jenkins 빌드를 다시 시작하려면 PR 아래의 주석에 jenkins build libelektra please 를 사용하거나
• 변경 없이 마지막 커밋을 다시 작성하고(예: git commit --amend ) 강제 푸시

. 불편을 드려 죄송합니다.

유지해주셔서 감사합니다!

v2-debian-buster 노드 가 제대로 작동하지 않는 것 같아서

인프라를 찾아주셔서 감사합니다!

v2에 디스크 공간이 부족합니다. docker system prune 실행

그런 다음 v2를 재부팅하고 에이전트를 다시 연결했습니다.

이제 du -h | sort -h 를 실행하여 제거할 다른 파일을 찾습니다.

새로운 Docker 버전으로 v2를 다시 시작했습니다. 손상된 빌드를 즉시 보고하십시오.

도커를 다시 설치하고 모든 구성을 제거하고 /var/lib/docker를 제거했습니다. 이 문제가 해결되기를 바랍니다.

v2가 다시 포함될 것입니다. 깨진 빌드를 즉시 보고하십시오.

여기에서 제안한 대로 지금 실행했습니다.

ethtool -K enp3s0 sg off # on v2
ethtool -K enp0s25 sg off # on i7
ethtool -K enp37s0 sg off # on a7 (internal network interface)

그리고 i7도 다시 시작했습니다(많은 docker 네트워크 인터페이스가 있었지만 지금은 사라졌습니다)

docker-ce는 이제 어디에나 있습니다 5:19.03.1~3-0~debian-buster

손상된 빌드를 즉시 보고하십시오.

master 빌드가 v2-debian-buster 대한 연결 문제 때문에 다시 실패한 것 같습니다 (문제 #2995 참조).

관리자에게 a7/v2/i7 간의 전환을 살펴보라고 요청했습니다. 지금은 v2와 i7을 비활성화했습니다.

libelektra/master 및 libelektra-daily를 다시 시작했습니다.

3대의 PC 모두 포트를 변경했습니다.

그런 다음 v2/i7에서 jenkins homedir을 제거하고 v2/i7 에이전트를 다시 시작했습니다.

v2-debian-buster 에 더 이상 사용 가능한 공간 이

ApplyLayer 종료 상태 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: 장치에 남은 공간 없음

.

보고해 주셔서 감사합니다. v2에서 (훨씬) 더 많은 공간을 확보했습니다.

작업 제거 완료:

사용된 파일 시스템 크기 가용 사용량(%)이 마운트됨
/dev/sda3 417G 227G 164G 58% /

마이그레이션으로 인해 빌드 서버가 다운되었습니다(새 빌드 서버의 백업에서 일관된 상태를 얻도록).

https://build.libelektra.org/jenkins/ 가 다시 시작됩니다.

백업 중 커널 오류로 인해 빌드 서버의 로드가 200이었고 서버가 더 이상 반응하지 않아 재설정해야 했습니다.

로그 메시지는 (예시):

[87400.120008]  [<ffffffff810be6a8>] ? find_get_page+0x1a/0x5f

[87372.120005]  [<ffffffff81357f52>] ? system_call_fastpath+0x16/0x1b
[87372.120005] Code: f6 87 d1 04 00 00 01 0f 95 c0 c3 50 e8 d7 36 29 00 65 48 8b 3c 25 c0 b4 00 00 e8 d0 ff ff ff 83 f8 01 19 c0 f7 d0 83 e0 fc 5a c3 <48> 8d 4f 1c 8b 57 1c eb 02 89 c2 85 d2 74 16 8d 72 01 89 d0 f0
[87372.120005] Call Trace:
[87372.120005]  [<ffffffff810be6cc>] ? find_get_page+0x3e/0x5f
[87372.120005]  [<ffffffffa016962f>] ? lock_metapage+0xc2/0xc2 [jfs]

[87400.110012] BUG: soft lockup - CPU#0 stuck for 22s! [cp:15356]

다음 주 초에 곧 마이그레이션할 수 있기를 바랍니다( @Mistreated ?)

서버는 현재 레이드를 재동기화하고 있으므로 매우 느릴 것으로 예상됩니다.

Jenkins 빌드는 더 이상 수행되지 않습니다. #3035 참조

Jenkins는 이제 다시 시작했습니다. Jenkins 빌드 작업을 반복하십시오.

v2-debian-buster 이 오프라인 상태인 것 같습니다.

a7.complang.tuwien.ac.at:22221에 대한 SSH 연결 열기.
연결 거부됨(연결 거부됨)

.

감사합니다. 관리자에게 연락했지만 이미 부재중일 것 같습니다.

Herbert는 어제 v2를 이미 다시 시작했습니다. 그는 "동시 멀티스레딩"을 비활성화했습니다.

서버(v2, i7, a7)가 다시 충돌하는 경우 "herbert at complang.tuwien.ac.at"를 통해 관리자에게 직접 문의하시기 바랍니다. 여러 이메일을 피하기 위해 여기에서도 신고해 주세요.

v2-debian-buster 의 master 분기에 대한 Git 저장소에 문제 가 있다고 생각합니다.

git fetch --tags --progress https://github.com/ElektraInitiative/libelektra.git +refs/heads/master:refs/remotes/origin/master +refs/heads/*:refs/remotes/origin/* --prune" returned status code 128:
stdout: 
stderr: error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
error: object file .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117 is empty
fatal: loose object 9c0bc3ca6fcbc610abd845aeff5f666938d24117 (stored in .git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117) is corrupt
fatal: the remote end hung up unexpectedly

. 이미 빌드를 세 번 다시 시작했지만 Jenkins는 항상 동일한 오류로 실패합니다.

불행히도 v2에는 때때로 파일을 손상시키는 것으로 보이는 btrfs가 있습니다. docker pull 실패로 이미 비슷한 문제가 있었습니다. 현재의 경우 0bc3ca6fcbc610abd845aeff5f666938d24117 파일이 손상된 것 같습니다. 이 파일의 발생에 대해 md5sum을 실행할 때 다음을 얻습니다.

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

이제 마스터의 전체 디렉토리를 제거하고 빌드를 다시 시작했습니다. 참조 #3054

저는 이제 며칠 동안 자리를 비울 수 있으므로 연결할 수 없는 a7/i7/v2에 관한 문제에 대해 "herbert at complang.tuwien.ac.at"에게 연락하십시오. @Mistreated 는 서버 재부팅과 관련이 없는 모든 것을 책임집니다. (곧 새로운 빌드 에이전트가 제공되기를 바랍니다.)

또한 여러 이메일을 피하고 모든 사람이 현재 진행 중인 상황을 잘 파악할 수 있도록 항상 여기에서 보고해 주십시오.

현재 빌드 서버에 오작동이 있습니까?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

현재 빌드 서버에 오작동이 있습니까?

기본 Jenkins 빌드 서버가 i7 연결할 수 없는 것 같습니다. 노드를 일시적으로 오프라인으로 표시했습니다.

임의의 경우 빌드가 실패합니다.
여기에서 아무 이유없이 중단되었습니다
여기 내 PR과 관련이 없는 테스트 케이스가 실패합니다(저는 방금 코드를 건드리지 않고 디자인 결정을 추가했습니다)

여기에서 아무 이유없이 중단되었습니다

두 개의 PR에 대해 동일한 중단 코드 143을 얻었지만 아직 설명할 수 없습니다. 빌드를 다시 시작했고 지금 작동하기를 바랍니다.

여기 내 PR과 관련이 없는 테스트 케이스가 실패합니다.

이것은 #3103이 있는 @sanssecours 덕분에 수정되어야 합니다. 마스터로 리베이스하십시오.

새로운 Jenkins 노드 hetzner-jenkins1 가 제대로 작동하지 않는 것 같습니다 . 노드를 일시적으로 오프라인으로 표시했습니다.

i7에서 도커를 업그레이드하고 컴퓨터를 다시 시작했습니다. 이 문제가 해결되기를 바랍니다. 에이전트가 다시 온라인 상태입니다. 여기에서 문제를 보고하십시오(및/또는 에이전트 비활성화).

현재 #3065의 작업이 i7에서 실행 중입니다.

@Mistreated hetzner-jenkins1을 디버그할 수 있습니까?

링크 체크를 잠시 끌 수 있는 가능성이 있나요?

이것은 하루 종일 일어나고 있습니다.

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

다른 PR(최근 #3115, #3113)도 영향을 받습니다. downforeveryoneorjustme 에 따르면 링크를 실제로 사용할 수 없습니다.

업데이트: 웹사이트가 아직 오프라인 상태입니다. 이 #3117을 위해 PR을 했습니다.

링크 체크를 잠시 끌 수 있는 가능성이 있나요?

테스트/linkchecker.whitelist에 추가하여 개별 링크를 끌 수 있습니다(이미 알아낸 것처럼)

Cirrus에서 실패한 빌드를 다시 실행할 수 없습니다. https://github.com/ElektraInitiative/libelektra/pull/3113 참조
https://cirrus-ci.com/build/6562476467945472

버튼은 아무 작업도 수행하지 않습니다. 그것을 작동시키는 마술 트릭이 있습니까?

편집: 누군가가 무언가를 변경했거나 x`번째 시도가 마침내 성공했습니다. 빌드가 다시 실행 중입니다! :)

a7-debian-buster 빌드 에이전트를 다시 시작할 수 없는 것 같습니다.

…
[10/28/19 06:02:59] [SSH] Starting slave process: cd "/home/jenkins" && java  -jar slave.jar
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout

.

편집: 누군가가 무언가를 변경했거나 x`번째 시도가 마침내 성공했습니다. 빌드가 다시 실행 중입니다! :)

귀하의 의견을 본 후 "실패한 빌드 작업 다시 시작" 버튼도 눌렀습니다. 내가 말할 수있는 한 버튼을 누르면 실제로 실패한 빌드 작업이 다시 시작되었습니다.

귀하의 의견을 본 후 "실패한 빌드 작업 다시 시작" 버튼도 눌렀습니다. 내가 말할 수있는 한 버튼을 누르면 실제로 실패한 빌드 작업이 다시 시작되었습니다.

그것은 나를 위해 작동하지 않았다, 나는 다음 번에 약간의 gif를 제공할 것이다!

빌드 서버와 해당 노드를 다시 시작하겠습니다. #3121 및 #3099의 빌드 작업은 죽은 에이전트에 대한 작업이 있으므로 다시 시작해야 합니다.

그것은 나를 위해 작동하지 않았다, 나는 다음 번에 약간의 gif를 제공할 것이다!

이미 당신을 믿고 있기 때문에 GIF를 제공할 필요가 없습니다 😊.

jenkins가 중지하는 데 문제가있는 것 같습니다. 모든 Java 프로세스를 강제로 종료하기 전에 조금 기다립니다.

또한 모든 에이전트에서 도커를 업그레이드했습니다(i7에서는 이미 업그레이드됨).

Jenkins는 #2984에서 제안한 대로 하트비트 간격으로 다시 작동합니다. 모든 노드가 연결됩니다.

필요에 따라 모든 작업을 다시 시작하고 문제가 있으면 여기에 보고하십시오.

v2가 다운되었습니다. 관리자에게 다시 시작하도록 요청했습니다.

v2가 실행되고 빌드 백로그의 크기가 적절하기 때문에 다시 활성화했습니다.

빌드에 다시 문제가 있습니까( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

빌드에 다시 문제가 있습니까( hetzner-jenkins1 )?

예 . 노드를 비활성화했습니다.

디스크 할당량이 초과되었습니다. 메모리로 과도하게 사용하고 싶지 않았습니다. 나는 그것을 지금 청소했다. 다시 올라왔습니다.

노드가 업데이트되었습니다.

hetzner-jenkins1을 4개의 병렬 빌드로 늘렸습니다. 아무 것도 실행되지 않는 한 이는 임시 조치일 뿐입니다.

testsuite가 시간 초과됨에 따라 hetzner-jenkins1의 실행자 수를 4개에서 2개로 일시적으로 줄였습니다. 테스트가 실행되는 동안 너무 많은 작업이 컴파일될 때 이런 일이 발생한다고 생각합니다. 다른 작업을 너무 많이 방해하지 않는 단일 컨테이너에서 사용 가능한 리소스를 제한해야 할 수도 있습니다.

이것이 잘못된 접근이라고 생각되면 자유롭게 수정하십시오.

편집: 테스트가 여전히 시간 초과되고 지속적으로 재구축하면 더 많은 리소스가 낭비되므로 1로 줄였습니다.

@mpranj 수정 해주셔서 감사합니다!

@mistreated 단일 CPU 또는 이와 유사한 것만 할당했습니까? 더 많이 할당하고 실행자 수를 높일 수 있습니까? 하드웨어는 v2만큼 강력해야 합니다.

디스크 공간이 남아 있지 않아 모든 빌드가 실패하기 때문에 i7-debian-buster 비활성화했습니다. 누군가 액세스 권한이 있는 경우 무언가를 정리하고 다시 활성화하십시오.

@mpranj 비활성화

죄송합니다. 현재 내가 있는 곳에서 ssh가 차단되었습니다(일부 애플리케이션 방화벽, 다른 포트의 ssh도 작동하지 않음). 그래서 지금은 액세스 권한을 부여하거나 정리할 수 없습니다.

i7은 에이전트 중 가장 약하기 때문에 어쨌든 큰 문제가 아닐 수도 있습니다.

@Mistreated 단일 CPU 또는 이와 유사한 것만 할당 했습니까? 더 많이 할당하고 실행자 수를 높일 수 있습니까? 하드웨어는 v2만큼 강력해야 합니다.

v2가 얼마나 강력한지 모르겠습니다.
현재 jenkins1 는 8개의 메모리와 16개의 스왑이 있는 4개의 CPU를 사용합니다. 나는 그것을 쉽게 늘릴 수 있지만, 당신이 내가 그것을 늘리기를 원하는 지점을 모르겠습니다.

미래의 하드웨어 결정에 대한 참고 사항: phoronix는 CPU 기사에서 컴파일 테스트를 수행하는 것으로 보입니다(예: Ryzen 7 3700X, Ryzen 9 3900X 테스트, 기사 하단 부분 ).

hetzner가 최근 AMD 기반 서버에 AMD Ryzen 7 3700X를 추가한 것 같습니다.

v2가 얼마나 강력한지 모르겠습니다.

@ingwinlu 는 그의 논문에서 이에 대해 썼습니다(abgaben repo lukas_winkler에서 찾을 수 있음)

현재 jenkins1은 8개의 메모리와 16개의 스왑이 있는 4개의 CPU를 사용합니다. 나는 그것을 쉽게 늘릴 수 있지만, 당신이 내가 그것을 늘리기를 원하는 지점을 모르겠습니다.

서버에서 실행 중인 다른 것이 없는 한 모든 리소스를 할당할 수 있습니다. 나중에 우리는 여전히 내려갈 수 있습니다(Jenkins를 이동할 때).

hetzner-jenkins1을 업데이트했습니다.
프론트엔드에서 메모리가 부족한 오류가 수정됩니다.
이제 2개의 병렬 빌드를 실행합니다.

v2-debian-buster 에 남은 공간 이

validation.cpp:69:1: fatal error: error writing to /tmp/cccJFleY.s: No space left on device

.

감사합니다. 누군가가 이를 정리할 수 있을 때까지 오프라인에서도 표시했습니다.

디스크 할당량이 초과되어 hetzner-jenkins1 방금 3개의 PR에 실패했습니다. 다음은 출력에 있습니다.

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on hetzner-jenkins1
/home/jenkins/workspace/libelektra_PR-3106-LB35J55FSRLFKFEU2WP6AWVLM3IH4JWI6C5B57NWB6DDARN4JDUA@tmp/ff803792-a127-4b8f-8588-439af982c8a4: Disk quota exceeded

디스크 할당량이 초과되어 hetzner-jenkins1 을 오프라인으로 표시했습니다.

i7 및 v2를 정리했습니다( /home/jenkins/workspace/* 제거 및 docker system prune ). 이제 다음이 있습니다.

• i7: /dev/mapper/i7--vg-home 199G 152G 37G 81% /home
• v2: /dev/sda3 417G 255G 147G 64% /

그런 다음 에이전트를 다시 시작했습니다.

@Mistreated 너무 빨리 재발하지 않도록 #3160을 수정해 주세요. hetzner-jenkins1도 수정하십시오. 이 시스템에는 많은 리소스가 있습니다. 매일 리소스 한도에 도달할 필요는 없습니다.

디스크 크기를 줄이는 좋은 방법이 있는지 모르겠습니다. 내가 노드에 모든 것을 한 번에 제공하지 않는 이유는 .. hetzner가 다시 작동합니다.

v2가 다시 공간이 부족하여 정리했습니다. /dev/sda3 417G 315G 102G 76% /

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log 가 시작되지 않습니다.

현재 빌드 시스템이 완전히 중단되어 PR이 빌드되지 않고 있다고 생각합니다.

보고해 주셔서 감사합니다. 디스크가 가득 차면 Jenkins를 다시 시작하고 일부 파일을 정리하겠습니다.

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log 가 시작되지 않습니다.

에이전트가 성공적으로 연결되었으며 온라인 상태입니다.

이제 hetnzer-jenkins1로 모든 것이 정상이라고 가정합니까?

정말 고맙습니다! Jenkins가 여전히 빌드에 반응하지 않는 것 같습니다. : v2 및 I7 지금은 모두 실패 java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Jenkins가 다시 작동합니다. 작업을 다시 시작하십시오.

java.io.IOException: slave.jar을 슬레이브의 '/home/jenkins'에 복사할 수 없습니다.

고정됨(공간이 부족함)

@Mistreated jenkins-daily를 수정하십시오. 이렇게 하면 이제 항상 수동으로 수행해야 하는 정리 작업이 생성됩니다!

@Mistreated "jenkins build libelektra please"가 여전히 깨졌습니다. 이것이 웹훅의 변경 사항과 관련이 있습니까?

오늘은 새로운 Jenkins로 변경을 시도해볼 수도 있지만 그렇게 할 수 없다면 이전 인스턴스가 다시 작동하도록 해주세요!

저장소 스캔을 트리거했는데 이제 "jenkins build libelektra please"가 다시 작동하는 것 같습니다.

v2-debian-buster 의 디스크가 가득 찬 것 같습니다.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

안타깝게도. 해결될 때까지 v2 를 오프라인으로 표시했습니다.

신고해 주셔서 감사합니다!

@mpranj 액세스 권한을 주었습니다. 정리 좀 해 주시겠습니까?

감사합니다! 도커의 오래된 이미지가 주변에 널려 있어 낭비되는 리소스가 많은 것 같습니다. 또한 btrfs + docker가 버그가 있는 것 같습니다. Docker는 각 컨테이너에 대해 btrfs 하위 볼륨을 만들고 나중에 제대로 정리하지 않습니다. docker system prune -f 명령은 공간을 확보하지도 않습니다.

리소스를 확보하고 btrfs의 균형을 유지하기 위해 유지 관리를 위해 v2 및 a7 갔습니다.

도커 로그인 실패

캔트 풀 도커 이미지를 빌드하십시오. 도커 허브에 무슨 일이?

예, 죄송합니다. a7 로 도커 허브도 제거했습니다. 다시 올라오면 여기에 글을 올리겠습니다.

a7 도커 허브를 포함하여 다시 작동합니다. 이미지를 가져오기 위해 허브에 로그인할 수 없기 때문에 v2 오프라인 상태로 두었습니다!? 나는 거기에 무엇이 잘못되었는지 모르고 자격 증명을 변경하지 않았으며 다른 노드는 로그인할 수 있습니다. 어떤 아이디어?

Btrfs는 여전히 백그라운드에서 균형을 유지하고 있으며 a7 는 한 시간 정도 더 느릴 수 있습니다.

@mpranj 이 문제를 해결해 주셔서 감사합니다! btrfs 재조정에 어떤 명령이 필요했습니까?

불행히도 자격 증명을 알지 못합니다. @ingwinlu 가 우리를 도울 수 있기를 바랍니다.

균형을 재조정하는 데 사용한 명령은 다음과 같습니다.

btrfs로 아마도 버그를 수정하십시오:

btrfs balance start -dusage=0 -musage=0 /mountpoint

fs의 균형을 다시 조정하는 데 시간이 오래 걸립니다. 사용법 매개변수는 조정될 수 있거나 조정되어야 합니다. 이것이 오늘 작동한 것입니다.

btrfs balance start -dusage=80 /

자격 증명은 쉽게 변경할 수 있지만 새 자격 증명으로 도커 허브에 다시 연결하는 모든 젠킨스 에이전트에 로그인해야 합니다.

더 큰 문제는 일부 도커 컨테이너가 여전히 실행 중이고 도커 시스템 정리가 많은 일을 하지 않았다는 것입니다. 따라서 에이전트를 중단하고 중단된 동안 모든 것을 해제했습니다. TONS 의 컨테이너가 단지 주위에 누워있었습니다.

예, 불행히도 컨테이너는 빠르게 재생성됩니다. @Mistreated 가 libelektra-daily 작업을 곧 고칠 수 있기를 바랍니다( docker system prune ).

나는 또한 꽤 관련된 디지털 포렌식을 수행하고 허브 자격 증명을 훔쳤습니다. :웃음:

v2 이(가) 다시 실행 중입니다.

정말 고맙습니다! :100: 자격 증명을 보내주십시오.

전송 된. Btw 내 생각에 a7 는 디스크 속도가 느리기 때문에 느릴 수 있지만 도커 허브에 충분한 공간이 있는 것이 좋습니다. CPU가 아무 것도 하지 않는 경우가 많은 것 같습니다.

또 다른 생각: 지금과 같은 상황을 피하기 위해 cronjob당 추가로 중요한 정리 작업을 수행할 수 있습니다.

자격 증명을 보내주십시오.

@mpranj 저는 이 "우리" 그룹에 있었던 것 같아요. 나는 일부 CC 또는 그와 비슷한 것에 없었습니까?

@Mistreated 죄송합니다. Markus에 이메일을 보냈는데 귀하의 이메일이 없습니다. a7 의 homedir에서 CREDENTIALS.txt 를 찾을 수 있습니다.

새로운 jenkins-server를 테스트하려면 hetzner-jenkins1 노드가 필요합니다. 내일 아침까지 기존 서버를 끌 예정입니다.

테스트용으로 두 번째 hetzner-jenkins2를 쉽게 만들 수 있습니다. 이 밤만이라면 괜찮겠지만.

또 다른 생각: 지금과 같은 상황을 피하기 위해 cronjob당 추가로 중요한 정리 작업을 수행할 수 있습니다.

libelektra-daily는 이 정리 작업을 수행하지만 지금은 실패합니다: #3160. 이 작업을 개선할 아이디어가 있으면 알려주십시오.

나는이 "우리"그룹에 있다고 생각합니다. 나는 일부 CC 또는 그와 비슷한 것에 없었습니까?

네, 죄송합니다. "우리"가 당신을 의미한다고 mpranj에게 말하는 것을 잊었습니다.

나는 잠시 동안 hetzner-jenkins1 을 유지하는 것이 좋기를 바랍니다. 모든 빌드가 이제 괜찮습니다. 이제 오늘 밤 서버를 완전히 실행할 수 있다고 생각합니다.

v2 에 연결할 수 없습니다. 관리자에게 문의했습니다.

나는 hetzner-jenkins1을 잠시 동안 유지하는 것이 괜찮기를 바랍니다. 이제 모든 빌드가 좋아 오늘 밤 서버를 완전히 실행할 수 있다고 생각합니다.

이것은 좋을 것입니다!

v2에 연결할 수 없습니다. 관리자에게 문의했습니다.

감사합니다만 월요일 이전에는 응답하지 않을 것 같습니다.

v2는 새로운 커널을 얻습니다(방금 충돌했습니다).

i7도 다시 시작됩니다.

3개의 서버(v2, a7, i7) 모두 이제 "Linux v2 5.2.0-0.bpo.2-amd64 #1 SMP Debian 5.2.9-2~bpo10+1 (2019-08-25) x86_64 GNU/Linux "

작동 중이며 필요한 경우 작업을 다시 시작하십시오.

참고 사항:
새 서버로 repo를 다시 스캔했습니다. 이것은 이전 버전에서 약간의 오류를 만들 수 있습니다.

master [1]도 새 서버에 구축된 것 같습니다. 성공적이지 못했습니다. 상태를 클릭하면 로그인 페이지가 나타납니다[2]. 로그인하지 않고도 모든 것을 볼 수 있도록 Jenkins를 재구성하십시오.

곧 새로운 Jenkins로 전환할 수 있기를 바랍니다. 두 개의 다른 Jenkins에서 오류를 확인한다고 해서 상황이 더 쉬워지는 것은 아닙니다.:wink:

[1] https://github.com/ElektraInitiative/libelektra/commits/master#
[2] http://95.217.75.163 :8080/login?from=%2Fjob%2Flibelektra%2Fjob%2Fmaster%2F1%2Fdisplay%2Fredirect

@markus2330 업그레이드 후 원격으로 a7/v2를 재부팅할 수 있습니까? 아니면 몇 가지 함정이 있습니까?

일반적으로 작동하지만 급하지 않은 경우 관리자가 있을 때까지 기다리는 것이 좋습니다. 괜찮으시다면 화요일에 재부팅해도 될까요?

감사합니다! 급한건 없고 그냥 일반적인 질문입니다. 데비안 10.2가 출시된 지 얼마 되지 않았기 때문에 나온 것입니다. 업그레이드와 함께 조금 기다리겠습니다.

그럼에도 불구하고 업그레이드를 수행할 수 있습니다(재부팅 없이만). 그런 다음 충돌이 발생한 경우 관리자가 재설정 버튼을 누를 때 이미 10.2 커널을 갖게 됩니다.wink:

@mpranj 오래된 스냅샷을 제거하는 cronjob을 추가할 수 있습니까? 아니면 도커를 중지하지 않고는 불가능합니까?

https://docs.docker.com/storage/storagedriver/btrfs-driver/ 는 cronjob에서 btrnfs의 균형도 재조정할 것을 권장합니다.

이전 스냅샷을 제거하는 cronjob을 추가할 수 있습니까? 아니면 도커를 중지하지 않고는 불가능합니까?

모든 도커 컨테이너를 중지하지 않고 cronjob을 추가할 수 있습니다. 이것은 모든 것을 정리할 수는 없지만 시도해 볼 수 있습니다. 내가 말했듯이 때때로 컨테이너는 기계가 충돌할 때까지 영원히 계속 실행됩니다. 완전한 정리를 위해서는 빌드 에이전트를 일시적으로 비활성화해야 하지만 모든 컨테이너를 강제로 중지할 수 있습니다.

재조정을 cronjob으로 추가할 수도 있습니다.

감사합니다. 시도해 보겠습니다.

마스터의 메모리가 부족합니다. a7 및 i7이 도커 이미지를 가져올 때 다음 오류가 발생하기 때문에 이전 Jenkins에서 Scan Repository를 실행하고 싶었습니다.

도커 로그인 실패

이제 새 서버에서 v2와 hetzner-jenkins1이 실행되고 있습니다.

마스터의 메모리가 부족합니다.

신고해 주셔서 감사합니다. 일부 오래된 커버리지 데이터를 제거하고 마스터 노드를 다시 활성화했습니다. 열려 있는 풀 리퀘스트가 있는 모든 사용자: jenkins build libelektra please Jenkins 빌드를 다시 시작하세요. 불편을 드려 죄송합니다.

#3234 @raphi011에서 다음과 같이 제안했습니다.

이것은 정말 시급합니다. 테스트의 취약성과 느림으로 인해 테스트를 확인하기 위해 이렇게 오래 기다려야 하는 경우 변경을 수행하는 것이 불가능하지는 않더라도 어렵습니다.

나는 그것이 정말로 시급하다는 데 동의하지만 @Mistreated는 이미 그가 할 수 있는 일을 하고 있습니다.

따라서 빌드 서버를 더 적게 사용할 수 있으며 PR이 곧 병합될 것이라고 정말로 생각하는 경우에만 빌드할 수 있습니다. 불필요한 빌드는 취소해야 합니다.

또는 변경 사항을 푸시할 때 PR의 자동 빌드를 (일시적으로) 중지하는 것은 어떻습니까(따라서 빌드는 jenkins build libelektra please 로만 시작됨)? @Mistreated Jenkins를 재구성하는 방법을 알고 있습니까(옵션을 찾지 못함)?

나는 또한 jenkins build libelektra please 이 현재 작동하지 않는다는 느낌이 https://github.com/ElektraInitiative/libelektra/pull/3073 파이프라인을 시작하기 위한 빈 커밋.

클린업 cronjob 구현 및 백포트 커널이 7 및 v2에서 업그레이드되었습니다. 커널에 대한 변경 로그가 상당히 많으며 다음 재부팅 시 활성화됩니다.

매우 감사합니다! "이전" 백포트 커널이 여전히 설치되어 부팅되지 않는 경우 대체할 수 있습니까?

예, 새 커널로 성공적으로 부팅한 후 제거할 수 있습니다.

Starting pull/hub.libelektra.org/build-elektra-alpine:201911-78555f42df1da5d02d2b9bb9c131790fcd98511c3dea33c6d1ecee06b45fae55/ on i7-debian-buster

docker login failed

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3244/1/pipeline

수동 정리, 커널 및 도커 업그레이드를 위해 i7 를 비활성화했습니다. 내가 작업하는 동안 누군가 i7 를 활성화했습니다. 모든 것이 다시 실행되고 있습니다.

@Piankero 지금 빌드를 다시 시작했습니다.

나는 또한 jenkins build libelektra please 가 현재 작동하지 않는다는 느낌을 받았습니다. 적어도 이 빌드에서는 작동하지 않았습니다. #3073 파이프라인을 시작하기 위해 빈 커밋을 푸시해야 했습니다.

지금 작동

@Mistreated Jenkins를 재구성하는 방법을 알고 있습니까(옵션을 찾지 못함)?

Jenkins 구성에 다음을 추가했습니다.

자동 SCM 트리거 억제

모두를 위한 참고 사항: "jenkins build libelektra please"의 사용은 이제 필수입니다. 빌드 작업은 단순히 푸시하는 것으로 시작되지 않습니다. 이 설정을 되돌리면 여기에 알려드리겠습니다.

@ 고맙습니다! 이 정도면 봅시다. 마스터에 대한 푸시가 여전히 마스터 빌드를 트리거하기를 바랍니다.

그럼에도 불구하고 hetzner 노드를 갖는 것은 매우 좋을 것입니다. 2개의 빌드 서버에서 동시에 노드를 사용하는 경우 문제가 있습니까? 또는 문제가 되는 경우: 단순히 CT를 복제하는 것이 매우 쉽지 않습니까?

@ 고맙습니다! 이 정도면 봅시다. 마스터에 대한 푸시가 여전히 마스터 빌드를 트리거하기를 바랍니다.

마스터 브랜치는 이제 다음 규칙의 예외입니다.

자동 SCM 트리거 억제

에 관해서는

그럼에도 불구하고 hetzner 노드를 갖는 것은 매우 좋을 것입니다. 2개의 빌드 서버에서 동시에 노드를 사용하는 경우 문제가 있습니까? 또는 문제가 되는 경우: 단순히 CT를 복제하는 것이 매우 쉽지 않습니까?

새로운 CT(hetzner-jenkinsNode3)를 추가했습니다.

저장소를 복제할 수 없습니다: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

아마도 이것은 새로운 노드와 관련이 있습니까? (엉뚱한 추측)

아마도 이것은 새로운 노드와 관련이 있습니까? (엉뚱한 추측)

이 오류는 7에 있습니다.

이 오류는 7에 있습니다.

너무 .. 다시 시도?

너무 .. 다시 시도?

네 또 안올거같아요..

다시 실행하겠습니다.

@Mistreated 자동 빌드를 다시 시작할 수 있다고 생각합니다. 하지만 먼저 #3160을 보십시오.

이것이 실패하는 이유를 알고 있습니까?

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

이것이 실패하는 이유를 알고 있습니까?

일시적인 문제인 것 같습니다. URL은 현재 빌드 에이전트에서 액세스할 수 있습니다.

장기적으로 각 빌드에 대해 반복적으로 다운로드하지 않도록 도커 이미지에서 이러한 종류의 종속성을 설정하는 것이 좋습니다. 또한 위에서 언급한 것처럼 일시적으로 사용할 수 없는 패키지로 인한 빌드 실패를 방지해야 합니다.

그럼.. jenkins build libelektra please 세번째

예, 바로 이러한 이유로 도커 이미지에 모든 종속성이 있습니다. 내가 만든 #3251

재부팅을 위해 v2 및 a7을 오프라인으로 전환했습니다.

@markus2330 기회가 된다면 a7 에서 하이퍼스레딩을 활성화하십시오.

v2가 다시 시작되었으며 7에는 여전히 빌드 작업이 있습니다.

노드를 가져와 새 서버에 추가했습니다. 밤새도록 하겠습니다. 새로운 Jenkins 서버에 추가 오류가 있으면 내일 노드를 반환하겠습니다.

hetzner-jenkinsNode3 는 이전 Jenkins에서 계속 실행됩니다.

새로운 Jenkins 서버에 추가 오류가 있으면 내일 노드를 반환하겠습니다.

작은 빌드 오류는 다시 전환해야 하는 이유가 아닙니다. 어느 시점에서 우리는 오류를 수정해야 합니다. 앞뒤로 이동하는 것은 매우 시간이 많이 걸립니다.

그러나 쇼 스토퍼가 될 수 있는 것은 새 서버에 연결할 수 없다는 것입니다. (어느 것도 아니다
http://95.217.75.163:8066 또는 ssh). 전원 버튼을 눌렀습니다. 기기가 다시 시작되는지 확인하겠습니다. 하지만 문제가 무엇인지 조사해야 합니다.

http://95.217.75.163 :8066

시간이 있다면 letsencrypt를 사용하여 TLS를 활성화하여 자격 증명을 유출하지 않고 다양한 다른 문제에 노출되지 않도록 하십시오.

입력해 주셔서 감사합니다! build.libelektra.org를 전환할 때 즉시 이 작업을 수행하는 것이 좋습니다. 그렇지 않으면 이중 노력이 필요합니다.

이 오류가 알려져 있습니까? Caught the following exception: null

형식 검사에 실패하고 다른 빌드가 종료된 것 같습니다.

네가 옳아. 그래도 무슨 엉터리 오류 메시지 : P

@Mistreated PR이 자동으로 생성되도록 다시 활성화해 주시겠습니까? 많은 에이전트로 인해 서버는 이제 대부분의 시간 동안 잠자기 상태입니다.

@Mistreated PR이 자동으로 생성되도록 다시 활성화해 주시겠습니까? 많은 에이전트로 인해 서버는 이제 대부분의 시간 동안 잠자기 상태입니다.

완료.

새 서버를 위해 hetzner-jenkins1 및 v2 다시 빌릴 것입니다.

돌려줄 필요는 없습니다. 오늘 전환할 수 있기를 바랍니다.

팁: 이러한 종류의 전환을 수행할 때 DNS 항목의 TTL을 비정상적으로 낮은 것으로 줄이는 것이 좋습니다(예: build.libelektra.org의 경우 현재 21599 대신 60). 변경 사항이 전파된 후 몇 시간이 아닌 1분 이내에 DNS 항목을 전환할 수 있습니다. 너무 늦으면 google 및 opendns의 DNS 캐시를 지우는 데 도움이 될 수 있지만 일부 사람들은 캐시된 항목이 전역적으로 만료될 때까지 불가피하게 이전 리소스를 보게 됩니다.

편집: 변경 후 TTL은 DNS에 대한 부하를 줄이기 위해 분명히 정상적인 값으로 되돌려야 합니다.

지금은 너무 늦었지만 $TTL 3600 로 전환했습니다(모든 것이 작동할 때까지 여러 변경이 필요한 경우).

www-new 및 build-new는 새 서버를 가리키는 이미 존재합니다.

이제 doc.libelektra.org로 전환했습니다. @Mistreated 는 게시를 수정합니다. www-new.libelektra.org를 살펴보겠습니다.

https://build-new.libelektra.org/ 및 https://www-new.libelektra.org/home 이 이제 작동합니다.

이제 모든 DNS 항목을 변경하겠습니다.

모든 DNS 항목이 변경됩니다.

불행히도 certbot은 이전 서버와 통신하는 것처럼 보이기 때문에 실패하지만 다운로드 및 커뮤니티(덜 사용되는 URL)에만 영향을 미치는 것으로 보입니다.

따라서 주말 동안/이후 모든 사람이 업데이트된 DNS 이름을 볼 수 있기를 바랍니다.

@Mistreated 는 모든 아티팩트의 게시를 업데이트하십시오. 웹사이트에서도 마찬가지입니다. 모든 것이 제대로 작동하는지 확인하기 위해 PR을 작성하십시오.

이제 이전 빌드 서버가 종료되었습니다.

새 서버를 다시 시작해야 합니다(새 커널 및 네트워크 브리지 추가됨).

Linux pve 5.0.21-5-pve로 서버가 다시 작동합니다.

모든 PR의 재검색을 예약했습니다.

pve의 잘못된 구성/버그로 인해 서버가 오프라인 상태입니다(/etc/network/interfaces가 GUI에 의해 삭제되었습니까?).

버그는 네트워크 장치의 이름을 바꾸면(GUI에서 내 작업으로 인해 발생) 커널 OOPS가 발생한다는 것입니다.

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

서버가 다시 가동되어야 합니다.

하지만 이전 문제가 남아 있습니다(작동하지 않는 구문 #3268)

@Mistreated 마스터도 더 이상 자동으로 빌드되지 않는 것 같습니다. 이제 수동으로 트리거합니다.

#3268에서 긴급 오류를 수집하고 있습니다. 모든 것이 doc/BUILDSERVER.md에 설명된 대로 작동하는지 테스트할 수 있다면 좋을 것입니다.

jenkins는 주어진 이유 없이 빌드하지 않습니다.
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

또 다른 빌드 오류: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

신고해 주셔서 감사합니다!

@Mistreated 이미 여러 번 논의한 대로 Naginator+Plugin #2967을 설치해 주시겠습니까? (젠킨스로 변경하기 전에 스냅샷을 만들어주세요.)

hetzner-jenkins1 : 디스크 할당량이 초과되었습니다.

@Mistreated 이미 여러 번 논의한 대로 Naginator+Plugin #2967을 설치해 주시겠습니까? (젠킨스로 변경하기 전에 스냅샷을 만들어주세요.)

오늘 할거야

hetzner-jenkins1: 디스크 할당량이 초과되었습니다.

@mpranj hetzner-jenkins1 가 다운된 동안 새로운 VM 를 빌드 에이전트로 추가했습니다.

docker system prune -a 를 실행하여 hetzner-jenkins1의 일부 공간을 정리하고 다시 활성화했습니다.

docker system prune -f 정리되지 않는 많은 것들이 다시 문제가 된 것 같습니다. 이번에는 스토리지 드라이버가 btrfs 아니라 vfs . :혼란스러운:

hetzner-jenkins1이 다운된 동안 새 VM을 빌드 에이전트로 추가했습니다.

이제 아이디어는 컨테이너를 더 이상 사용하지 않고 대신 VM만 사용한다는 것입니다.

docker system prune -a를 실행하여 hetzner-jenkins1의 일부 공간을 정리하고 다시 활성화했습니다.

매우 감사합니다! 거기에서 cronjob도 만들 수 있습니까? (컨테이너가 아닌 VM에서).

거기에서 cronjob을 만드세요?

완료.

@Mistreated 이미 여러 번 논의한 대로 Naginator+Plugin #2967을 설치해 주시겠습니까? (젠킨스로 변경하기 전에 스냅샷을 만들어주세요.)

naginator 플러그인을 원한다면 파이프라인에서 자유형 작업으로 이동해야 합니다. 대안을 찾겠습니다.

현재 jenkinsNode3VM VM에 대한 빌드가 실패합니다. 그들은 도커 풀을 할 수 없습니다:

unexpected EOF
script returned exit code 1

누군가가 문제를 해결할 때까지 지금은 비활성화했습니다.

[크론잡] 끝났습니다.

감사합니다!

naginator 플러그인을 원한다면 파이프라인에서 자유형 작업으로 이동해야 합니다. 대안을 찾겠습니다.

네, 좋은 생각입니다. Jenkinsfile에서 간단히 코딩하는 것이 가장 좋습니다. 따라서 문제가 있는 빌드 작업/단계가 실패하면 다시 시도됩니다. 이러한 도커 풀은 가장 자주 발생하는 문제 중 하나이므로 최소 두 번 시도합니다.

VM jenkinsNode3VM에 대한 빌드는 현재 실패합니다. 그들은 도커 풀을 할 수 없습니다:

@Mistreated 이 문제를 해결하십시오.

VM jenkinsNode3VM에 대한 빌드는 현재 실패합니다. 그들은 도커 풀을 할 수 없습니다

풀 수 없는 도커 이미지를 수정했습니다.

매우 감사합니다! 무엇이 잘못되었고 어떻게 고쳤는지 적어주시면 항상 도움이 됩니다.

무엇이 잘못되었는지 모르겠으며 에이전트에서 수동으로 이미지를 구축했습니다. 대리인이 당길 수 없기 때문입니다.

Dockerfile (scripts/docker/debian/stretch) 관해서는 my Visual Code 는 끝에 2개의 emtpy 라인이 있다고 말하지만 vim 는 하나만 말합니다. 위의 실수와 관련이 있는지 모르겠습니다. 아마도 VS 입니다.

도커 레지스트리에 문제가 있는 것 같습니다(#3316 docker pull이 unexpected EOF 실패함).

릴리스 후 먼지가 해결되고 빌드가 진행되지 않으므로 모든 것을 중지하고 레지스트리를 완전히 지우는 것이 좋습니다. 그 후에는 모든 이미지가 깨끗하게 다시 빌드되어야 합니다. 시작하기 전에 레지스트리 데이터를 백업하여 확실히 하려고 합니다. 하지만 클린 시작으로 우리가 갖고 있던 몇 가지 오류가 제거되기를 바랍니다.

시작하기 전에 반대 의견이 없는지 의견을 기다리겠습니다.

나는 그것이 문제라고 생각한다.

(스크립트/도커/데비안/스트레치)

이미지가 유일한 실패이기 때문입니다.

다시 수동으로 빌드했지만 레지스트리의 이미지에 문제가 있는 것은 확실합니다.

Jenkins 보고서: jenkinsNode3VM(오프라인)

@Mistreated 는 모니터링 방법을 설정할 수 있다면

a7 (따라서 v2 및 i7 )가 하락했습니다. 관리자에게 연락했습니다.

markus2330 수정: 다시

2020년 7월 8일 TU Wien에서 계획된 정전으로 인해 관리자는 전날(화요일 7.7)에 모든 빌드 서버를 종료할 계획입니다. 이 시간 동안 빌드가 매우 느려질 수 있으므로 긴급한 경우에만 해당 날짜를 푸시하세요.

서버는 i7을 제외하고 다시 온라인 상태입니다. 관리자에게 알렸습니다.

어제 저녁에 계획되지 않은 또 다른 정전이 발생하여 현재 모든 빌드 서버가 다운되었습니다. 관리자가 작업 중입니다.

30분 후 수정: i7을 포함한 모든 것이 다시 작동합니다.로켓:

@markus2330 v2와 i7이 최근에 인터넷 접속이 끊어진 것 같습니다(정전 중에?). 인터페이스가 정적으로 구성되어 있으므로 구성 변경 사항을 알고 계십니까?

나는 변경 사항에 대해 알지 못하며 이 두 번의 정전(하나는 계획되고 다른 하나는 계획되지 않음) 후에 컴퓨터가 다시 켜졌다는 사실만 알았습니다.

그러나 당신이 옳습니다. 나는 또한이 두 가지 (7은 아님)가 도달 할 수 있지만 더 이상 인터넷에 연결되어 있지 않다는 것을 알았습니다. 나는 그것에 대해 우리 관리자에게 물었다.

이 문제가 해결될 때까지 Jenkins에서 연결을 끊을 수 있습니까?

관리자에게 문의해 주셔서 감사합니다! 문제가 해결될 때까지 i7과 v2를 모두 연결 해제했습니다. (빌드는 도커 이미지를 가져올 수 없기 때문에 어쨌든 작동하지 않습니다)

약 1주일 전에 누군가 라우터로 무언가를 변경했습니다. 그 사람은 알림을 받았으며 곧 수정할 것입니다.

지금은 연결을 끊은 상태로 두도록 합시다.

이제 인터넷 문제가 해결되었으며 이 컴퓨터에 보안 업데이트도 설치했습니다.

@mpranj 다시 켜주시겠습니까?

@markus2330 감사합니다.

이제 모든 노드가 다시 온라인 상태입니다.

최신 PVE 커널용 빌드 서버를 재부팅했습니다. Jenkins는 곧 올라올 것입니다.

나는 움직였다

• [ ] 빌드 실패 시 이메일 보내기를 보다 안정적으로 만듭니다.
• [ ] Jenkins 사용자가 없는 Docker 이미지
• [ ] centOS/fedora/arch docker 이미지
• [ ] centOS 패키지
• [ ] freebsd/openbsd/solaris 빌드 에이전트

#3519 및 위의 #3519에 연결됩니다.

@robaerd는 이제 a7/v2/i7에도 액세스할 수 있으며 문제가 있는 경우 관리자에게 연락할 수 있습니다.

빌드 시간에 대한 간단한 보고서(메인 파이프라인 libelektra ):

• a7 사용: 2h 29m 24s
• a7 비활성화됨: 1h 35m 45s

Jenkins가 종료되었다고 표시하는 이유는 무엇입니까? 항상 여기를 미리 읽는 것이 좋습니다 :wink:

전체 시스템 백업과 btrfs에서 ext4로의 파일 시스템 재포맷 때문에 Jenkins가 종료됩니다.

젠킨스가 또 떴다

Jenkins CI는 오늘 약 11:15 CET부터 유지 관리를 위해 오프라인 상태가 됩니다.

몇 가지 백업 및 정리 작업을 수행하고 a7 성능을 개선하려고 합니다.

점검이 끝나면 다시 알려드립니다.

Jenkins CI 및 모든 빌드 서버가 다시 작동합니다. a7 성능이 훨씬 향상되지만 저장 용량이 줄어듭니다.

오류가 발생하면 신고해 주세요.

Jenkins CI 및 빌드 에이전트는 짧은 유지 관리/업데이트를 위해 오프라인 상태가 됩니다.

편집: 업데이트가 완료되었습니다.

서버가 다운되었습니다. 조사하겠습니다.

서버가 다시 작동합니다.

원인에 대한 공식 성명: "인접 서버의 PSU에 문제가 있어 서버가 종료되었습니다. 이제 수정되었습니다."

a7 의 ssd가 가득 차서 모든 빌드가 실패합니다.

공간을 좀 확보해 보도록 하겠습니다. 지금은 jenkins에서 a7 빌드 에이전트의 연결을 끊는 것이 안전합니까?

조사해 주셔서 감사합니다!

공간을 좀 확보해 보도록 하겠습니다. 지금은 젠킨스에서 7 빌드 에이전트의 연결을 끊는 것이 안전합니까?

당연하지. 반대로 모든 빌드가 실패하면 연결된 상태로 유지하는 것이 안전하지 않습니다.

docker system prune -a 실행하면 공간의 약 50%가 다시 정리되었습니다. -a 플래그를 추가하기 위해 기존 cronjob을 수정해야 할까요?

젠킨스 홈도 많은 공간을 사용하고 있습니다.

마스터 빌드(deb 패키지 및 웹 사이트 구축이 포함된 전체 파이프라인)는 모든 것이 녹색으로 보이지만 여전히 실패하고 있습니다. 어떤 아이디어?

community 에 대한 초점 deb 패키지 업로드는 elektra_0.9.3.orig.tar.gz 파일에서 실패합니다. 파일에 대한 권한 문제일 수 있습니다. 지금은 디렉토리에서 제거하고 다음 실행에서 다시 만들겠습니다.

어떻게든 sshPublisher가 실패하면 스테이지를 빨간색으로 설정하지 않습니다.

-a 플래그를 추가하기 위해 기존 cronjob을 조정해야 합니까?

이렇게 하지 않은 이유가 있었나요? 그렇지 않다면 좋은 생각처럼 들립니다.

Jenkins CI 및 a7 의 레지스트리는 망루 이미지를 새 버전으로 마이그레이션하기 위해 오프라인 상태가 됩니다. 몇 분 밖에 걸리지 않습니다.

편집: 업데이트가 완료되고 Jenkins CI가 다시 작동합니다.

Jenkins와 에이전트는 업데이트를 위해 잠시 중단됩니다.

편집: 모든 것이 업데이트되어 다시 실행되고 있습니다. a7 이 버스터 대신 데비안 스트레치 도커 패키지를 사용하는 문제를 수정해야 했습니다. 공간도 좀 정리했어요.

a7 에 공간이 없기 때문에 빌드가 실패합니다.

유지 관리를 위해 몇 분 동안 빌드 인프라를 사용할 수 없습니다.

빌드 인프라를 다시 사용할 수 있습니다.