Libelektra: サーバーのものを構築する

@ markus2330

ビルドシステム関連の修正をいくつかプッシュしました。 ただし、安定したdebian-stableマシンでもいくつかのパッケージを修正する必要があります。

• wheezy-backportsからqtdeclarative5-devをインストールしてください（後で/opt/Qt5.3.0を削除できます）
• java8をパッケージとしてインストールしてください。
  
  
  
  • この方法を使用してください： http ：
  
  
  • 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
  
  
  • ローカルのjenkinsjavaプロセスを強制終了して再起動します。 そうしないと、すべてのビルドが失敗します
  
  
  • オプション：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は機能しません）？
3.）elektra-gcc-configure-mingwにmingw + wineをインストールできますか？

apt install --no-install-recommends doxygen-latex + clang + mingwが完了しました

なぜワインが必要なのですか？

ところで、 Toolchain-mingw32.cmake i586-mingw32msvc-Xをi686-w64-mingw32-Xに変更する必要があります。 現在、これは不安定な状態では機能しません。

docuありがとうございます！

クロスコンパイルされたWindowsバイナリ（例：exporterrors.exe）を実行するにはwineが必要です

w64用にビルドされたmingwをインストールしたと思います。 mingw32パッケージには、まだ/usr/bin/i586-mingw32msvc-c++ます。

それでも、w64用の新しいツールチェーンファイルは高く評価されています。

i686をターゲットとしてmingwのx64ビルドであるgcc-mingw-w64-i686をインストールしました。
パッケージmingw32-binutilsは非推奨になり、不安定版では使用できなくなりました。

両方の容器にワインを取り付けました。

実際、mingwビルドはstableにバインドされているので、それは問題にはならないはずです。

MinGW-w64はmingwのフォークであり、まったく異なるターゲットです。 今まで誰もそれをテストしていませんでした。

ワインをインストールしてくれてありがとう

Mingw-w64は優れているように見えます。 多分それは先に進む時間です:-)

貢献を歓迎します;）私はそれをテストするためのマシンを持っていません。

私はあなたが間違ったワインを手に入れたのではないかと心配しています、それは適切なはずです-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ライブラリをインストールする必要はありません。

問題は、予備のjessieマシンがなく、wheezyのmingwがC ++ 11を認識していないことです。

私はなんとかmingw-w64を動作させることができました。 ただし、Windowsにはglibcがなく、std :: mutexはpthreadに依存しているため、std :: mutexは使用できません。 何か案は？

うわー、ありがとう！

コンパイルエラーにつながりますか？ std :: mutexは内部には使用されません
機能ですが、ユーザーがインクルードするヘッダーファイルにのみ含まれます。 使用されます
ただし、テストケースでは。

コンパイルの問題の1つの解決策は、mingwにstd :: mutexを提供することです。
ロック/ロック解除を試みるたびにシステムエラーがスローされるケース。 実際、私は
mingwの人々が少なくともそのようなものを提供することを期待してください（例えば
-D_GLIBCXX_USE_NANOSLEEPのように、いくつかのマクロが設定されます）

https://github.com/meganz/mingw-std-threadsは別の方法かもしれません。 しかし、それは
std :: mutexを含むものを除くすべてのテストケースの場合にのみ、おそらく有用です
すでに実行されています。

基本的に、これは適切に利用できないC ++ 11の1つのインスタンスにすぎません。

現在のmingwステータス：

• dlfcn-win32を外部プロジェクトとしてlibloaderに追加しました。 このようにして、cmakeは追加のビルドステップとしてライブラリをチェックアウト+コンパイルします。 追加のdlldepsを回避するために、アーカイブをリンクしています。
• winsock2.h / ws2_32.dllの依存関係をcpp11_benchmark_threadに追加しました。 gethostname（）で必要-呼び出し

現在、 -static-libgcc + -static-libstdc++ビルドしています。 そうしないと、wineはdllを見つけることができません。 追加のミューテックスもコンパイルされません。 mingw-std-threadsを試してみました。 コンパイルエラーが増えました:-)

x86_64-w64-mingw32-Xからx86_64-w64-mingw32-X-posixに切り替えると、pthreadのものが定義されているため、std :: mutexは正常にコンパイルされます。 ただし、libwinpthread-1.dllへの追加の依存関係があり、wineはこれを見つけることができません。

しかし、最善の策は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どう思いますか？ Windowsで最新の0.8.13mingw-w64ビルドをoyranosと一緒にテストする時間はありますか？

テストは通常​​、mingwビルドジョブに対して有効になっていますか？ 昨日、それらはすべて無効にされました。

はい、無効になっています。 しかし、 cpp11_benchmark_threadようなafaikの例/ベンチマークも無効にされました。 それで、あなたがそれを変更して、以前よりも多くコンパイルしたと思いました。

C ++ 11を有効にしてリポジトリ全体をコンパイルしました。 これ以上何もない。

ただし、-posixでビルドされたbin / basename.exeのような実行可能ファイルは、必要なdllをbinディレクトリにコピーする限り正常に実行されます（RPATHがないことを感謝します）。 a）cmakeにdllディレクトリを見つけさせる+ b）wineにdllディレクトリを指定する方法が見つかりませんでした。
静的リンクは機能すると思いましたが、elektra dllのリンク中に、シンボルが重複してビルドが失敗します。 dllにはすでにシンボルが含まれているためです。

@ markus2330dllをコピーせずにelektraをmingw + wineで実行してコンパイルすることができました。 秘訣は、実行可能オブジェクトと共有オブジェクトの両方に対して常に静的リンクを有効にすることです（ 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

作業の継続について：一方では、コンパイルされたものも実行されると便利です。 一方、リリースは今週末に行われるはずなので、プルリクエストはすぐに重要になります（少なくとも、バージョンスクリプトが実際に行うことなど、短いフィードバックサークルの可能性があるはずです）。

ただし、1つのバリアント（静的コンパイル）のみが機能する場合は、十分です。 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）にはさらにいくつかのパッケージが必要です。 インストールしていただけませんか：

• [] fakeroot
• [] gpg（+ Autobuilder [email protected]のキーを作成）
• [] reprepro（おそらくすでにインストールされており、スクリプトはこれまでに実行されていません）

fakerootがインストールされ、gpg + reproproはすでにインストールされています。
既存の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サポートが必要なのですか？

インストールしていただきありがとうございます！

python-devはJessieで利用でき、 python-supportも利用できます。 それらをインストールしてください。

ローカルでテストしました。これらのパッケージをインストールすると、jessie用にビルドされます。

確かに、それは利用可能ですが、それは間違った依存関係です。 python-devはpython2.7-devに依存していますが、これでは不十分です。 代わりに、python2.7-dev + python3-devが必要です。

python-supportはまったく必要ありません。

依存関係がこのように選択された理由はわかりません。ほとんどのパッケージ化は、 gsoc中に@iandonnellyによって行われました。

はい、python3バインディングをビルドするためにパッケージも更新する必要があります。 現在、それは単に行われていません。 それでも、ビルドが壊れないようにpython3-devをインストールできます（python3バインディング+プラグインがdebianパッケージに追加された場合）。

それはそれらが正しいという意味ではありません：-）-私はpython-devdepsについてかなり確信しています。
それらを置き換えて、python-support depを削除していただけますか？

python3-devおよびpython2.7-devはすでにインストールされています。 そうしないと、バインディングは構築されません。

ところで。 @pinotreeの公式debianパッケージは@pinotreeの作業は優れています。

時間があれば、「debian」ブランチを@pinotreeが公式パッケージで行ったことに更新します。 彼はすでに私たちにそうすることを許可しました。 qt-guiの更新を待ちます。現在、変更を急ぐ必要はありません。 また、python2をサポートすることは、1つのインストールで重要になります（チーターが使用されている場合、python3では機能しません）。

python2パッケージを削除すると言ったことはありません。 私が言っているのは、python-devは不正確な依存関係であるということだけです。 明示的なバージョンが必要です。 したがって、pythonX-devが使用する正しいdepです。

うまくいけば、pinotreeは依存関係を正しく解決しました。

ところで、チーターは死んでいます。 使用しないでください。

はい、交換しました。 結局、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は、デフォルトのPython2バージョンの開発パッケージをインストールします。 Wheezy以降、これはPython2.7です。
• python3-devは、デフォルトのPython3バージョンの開発パッケージをインストールします。 WheezyのPython3.2、Jessieの3.4、そして今のところStretchの3.4（まもなく3.5になると思います）

したがって、デフォルトのPython 2/3バージョンに対してビルドする場合は、 pythonX.Y-devバージョンではなく、それぞれpython-dev / python3-devを使用します（明示的に使用する場合に使用する必要があります）。システムにインストールされているのは1つだけではなく、デフォルトのバージョンでもない場合でも、正確な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はこれまでで最後のpython2devパッケージになります。

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をインストールしていただけませんか。 （manページを生成するために必要）

apt-get install ruby-ronn

終わり

おかげで、jessieパッケージが再びビルドされ、manページが含まれるようになりました。

muslをインストールしてください。

apt-get install musl musl-dev musl-tools

ありがとうございました！

muslがインストールされ、agendsがアップグレードされました

ビルドサーバーに関する2つの重要な点：

1. 新しい空のジョブを作成するのではなく、複製してください。正しい設定になっています（番号2に記載されているものを除く）。
2. 参照クローン（/ home / jenkins / libelektra内）を使用するか、すべてのビルドジョブに浅いクローンを使用する必要があります（現在、elektra-clangなどの一部に対してのみ実行されています）。 現在、不要な再クローンが多数あるため、コミット時のトラフィックは300MBを超えています。

@ mpranj2を修正できれば素晴らしいと思います。

@ markus2330念のため： elektra-clangように、すべてのビルドジョブに同じクローン動作を適用する必要がありますか？

以下を除くすべてのビルドジョブに適用される浅いクローン：

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-wheezy
• [] elektra-multiconfig-gcc-stable
• [] elektra-multiconfig-gcc-unstable
• [] elektra-source-package-test

これらのジョブは、いくつかのサブディレクトリにチェックアウトします。 何が欲しいのかわからなかったので、とりあえずそのままにしておきます。

ありがとうございました！ はい、完全な履歴とブランチが必要です。浅いクローンは意味がありませんが、参照クローンリポジトリは役に立ちます。

Jenkinsが1.651.2に更新されました。 また、すべてのプラグインが更新されました。

参照クローンリポジトリの問題を開いたままにします。 また、理想的にはjenkins自体を使用して、リポジトリを随時更新する「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プラグインに関連する奇妙なエラー、Mailerプラグインのダウングレードは役に立ちませんでした）。 そこで、すべてを最近のバージョンに再度更新しました。 この問題は、アップストリームの既知の問題のようです。

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

彼らがすぐにそれを修正することを願っています。

別の質問：誰かがPRごとに複数のジョブを実行する方法を知っていますか？ （elektra-mergerequests-stableとelektra-mergerequests-unstableの両方を実行したい）

elektra-test-bindingsジョブは、パラメーター化されたビルドで正常に機能しています（アップストリームチケットでも説明されています）。 パラメータ化されたビルドに切り替えることはできませんか？ バグはしばらくの間アップストリームで報告されていますが、すぐには修正されません。

すべてのPRジョブをパラメーター化されたビルドに変更することはできますが、実際には利点しかありません。 ブランチを指定することで、手動でジョブを実行することもできます。 また、通常のビルドジョブにも使用できます。

理想的には、すべてのジョブをgithubPRでも実行できます。 （特にマスターブランチのドキュメントまたはカバレッジを更新する非PRタスク用のものを除く）

elektra-test-bindingsの構成の欠点は、ポーリングのみを実行し、ビルドを開始するまでに非常に長い時間がかかることです（最大5分）。 ビルドジョブを中断しないように、「ビルドトリガーにgithubフックを使用する」をアクティブにしたくありません。

ところで。 「浅いクローン」オプションがgithubpullrequestビルダージョブで問題ないことを確認しますか？

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ごとに複数のジョブをトリガーできるかどうかはわかりません。 私はサブジョブをします。

ところで、私はすでにこれを数回言いましたが、仕事の量はばかげており、設定が台無しになっている兆候だと思います。 しかし、批判することは、何かを解決することよりも常に簡単です。

ビルドサーバーをデバッグする場合、5分が問題になります。 そして、私はまだ私たちがいつか、約5分かかる迅速な最初のテストを受けることを望んでいます。

ああ、わかりました。「ビルドトリガーにはトリガーフレーズのみを使用する」というオプションを見逃しました。 githubリクエストビルダーの設定は本当に混乱しています。

誰かが、PRごとに複数のジョブを実行しているgithubプロジェクトについて話しました。 （個別に表示）

サブジョブとは何ですか？ マルチジョブですか？

誰かが、PRごとに複数のジョブを実行しているgithubプロジェクトについて話しました。 （個別に表示）

githubに2つのサービスを追加する必要があります。

サブジョブとは何ですか？ マルチジョブですか？

ええマルチジョブ。

ところで、 https： //docs.travis-ci.com/はどうですか？ TravisはOSXをサポートしています。

jenkinsに置き換わるわけではありませんが、コミットビルドごとに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が未知の環境変数を削除する新しいセキュリティ測定を導入したため、これは壊れていました。 私は、追加（提案-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から/ etc / default / jenkins）。

追加のビルドサーバーの使用について：はい、先に進んでください。 また、単一のPRに対する複数のビルドジョブの問題も解決します;）私はtravis-ciを使用したことがないので、それについては何も言えません。 私はtravisがElektraInitiativeにアクセスできることを許可しました。

最初のtravisビルド： https ：
travisが何をすべきかを知るために、yamlファイルが必要だと思います。

そして、PRごとに複数のjenkinsジョブを実行する方法を理解しました。ビルドジョブごとに異なるコンテキストが必要でした。 次の会議では、「高速」およびその他のビルドジョブで何をすべきかについて話し合います。

私はtravisに取り組んでいます（またはいくつかのことをチェックしています）

楽しむ。 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バインディングは機能します。 Debianで不安定です。 何か案は？ 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

Dockerコンテナ内に構築されたDebian不安定版。 しかし、建物には時間がかかります。
良いアイデアはありますか？

clangはビルド時間に関しては速いことが多いですが、依存関係のインストールにはかなりの時間がかかると思います

使用されているものよりも最小限のDebianDockerイメージはありませんか？ 必要のないパッケージがたくさんインストールされているようです。

@sirblackheartどうしてそう思うの？ https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelmはおそらくdist-upgradeです。 ウェイランドのようにデスクトップ固有の多くのパッケージが更新されます

いいえ。distアップグレードは短いです。 多分分。 時間の約50％は、ビルド部門をインストールするために費やされます。

現在、ビルドイメージを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をトリガーします
• すべてを変更しても、プラグインとバインディングはコンパイルされません

私たちはまだジェンキンスで1日2回のフルビルドを持っています。

@manuelm良いアイデア、@ tom-waはそのようなスクリプトを書くでしょう、あなたはこれのために新しい問題を作成できますか？

@mpranj ：リマインダー：Mac OS Xビルドをtravisに追加し、mingwビルドをPRに追加します。 （* BSDはもっと努力しているようです）

@ markus2330 @manuelm dockerアプローチを理解しました。travisは来年まで、ubuntu 16.04をサポートしないため、

今日は会議に出席できなくてごめんなさい。 職場では、今日も大規模なソフトウェアの展開を準備しているため、オフィスを離れることはできません。 しかし、少し遅れて私は電子メールに答えることができます。

2日前にtravis用のOSXビルドの追加を開始しました： https ：
ビルドはこちら： https ：
ここで物事を開きます：

• [] cryto_opensslがコンパイルに失敗する
• []バインディングテストが失敗する
• [] Javaなし

ここから誰かが私の仕事を引き受けてくれたら嬉しいです。 私はOSXを持っておらず、travisがOSXシステムを検査するのを待っています。

re：docker：ええ、travisのデフォルトのubuntuバージョンはうまく機能しません。 cmakeでさえ古すぎます。
アップロードされたDocker画像の取得には約3分しかかかりません。 さらに画像を追加するのは簡単です。 したがって、これは、デフォルトのtravis linux環境にある（または更新後に発生する可能性がある）落とし穴を回避するための優れた方法だと思います。

libelektra（cmake + make + make test）のさまざまなビルドフェーズとテストフェーズをdocker（ビルド+実行）+ travis（before_install、before_script、script）と統合する良い方法がわかりませんでした。 コマンドの完了後、Dockerコンテナーは終了します。 Dockerコンテナは使い捨てであるため、後で再開することはできません。 したがって、ローカルディレクトリをコンテナにマウントしない限り、ディスク/コンパイルの状態は消えます。 来週もdockerの作業を続けます。

@manuelm素晴らしい、あなたはさらに進んだ、と私たちは思った。 PR用およびコミットごとのMacOSXは本当に素晴らしいでしょう。 現在、多くの人がMac OS Xを使用しているので、何度も何度もビルドを中断したくありません。 今日の会議で、 @ mpranjはあなたの仕事を

いいえ、travisファイルは後で変更する必要があるためです。 それ以外の場合は、OSXのみをビルドします。 @mpranjが私の取得し、残りのOSX関連の問題を修正することをお

PS：usernamespacedリポジトリでtravisテストを実行してください。 あなたはたくさんのプッシュをするでしょう:-)

mingw64は、追加されたPRに基づいて構築されており、機能するはずです。 遅れて申し訳ありません。 今日はトラビスを調べます！

PR内のフレーズでビルドジョブをトリガーできるようにすることの欠点はありますか（Github PRビルダーを使用）？

＃745のジョブを構成して、修正したかどうかをテストできるようにしたいのですが、ほとんどの/（すべての）ビルドジョブに適用できます。

編集：私はむしろすべての仕事を自動的に開始したくありません、私たちはすでにかなりの数を持っています。

すべてのジョブがフレーズでトリガーされるように構成できれば、それは良い考えだと思います。 （少なくともelektra-test-bindingsの場合）小さな欠点があると思います。ビルドするブランチを入力する必要があり、単に「今すぐジョブをビルド」を押すことはできません。 あなたがその解決策を見つけたら素晴らしいでしょう。

そして、あなたは私たちがむしろ自動ジョブを減らすべきであるということについて正しいです。

実際には非常に単純な解決策があります。 PRを構築するために（env）変数sha1を使用しています。 パラメータ化されたビルドは、デフォルト値が設定されているかどうかに関係なく、値の入力を求めます。

解決策：環境変数sha1を（jenkins構成自体で） master設定し、パラメーター化されたビルドを無効にします。 変数の設定に異議がない場合、これは上記の@ markus2330で述べたことを正確に解決します。

すでに設定しているので、たとえばelektra-mergerequestsビルドボタンを押すと、マスターのビルドが開始されます。

はい、これは非常に良い解決策です、私はそれが好きです。 また、単一のスイッチでリリースブランチを構築することもできます（将来必要になった場合）。 それまでは、PR内から実行されない場合、「マスター」が常に正しい選択です。

以前に持っていた、フィルタリングされた環境変数の問題も解決すると思います。

次に、ビルドジョブ（-mergerequest bulidジョブの重複なし）と新しい一貫した命名スキーマの削減についても考えることができます。 （提案はここで行うことができます。）1つの未解決の問題があるかもしれません：現在、PRとマスターの両方に対してカバレッジ、docu、..を構築し、それらを別々の場所にコピーします。 ビルドジョブをマージする場合、カバレッジ、ドキュメントを別の場所にコピーするために、ジョブマスター/ PRジョブ内で区別する方法が必要です。

これをすべてのジョブに適用することはほぼ完了しました（ただし、サーバーは非常に遅くなりました）。
ワイルドカードを作成するジョブには適用されませんでした**（docやその他のいくつかですが、ごくわずかです）

ビルドジョブを後で再起動すると（リリース時を除く）、作業したいときにいつでもビルドジョブを停止できます。 通常、ジェンキンス自体がマシンの速度低下の理由です。 現時点では、バックアップからのrsyncが問題になる可能性がありますが、緊急です。

ええ、まったく問題ありません、それは行われるべきですが、私はいくつかの最後のチェックをします。

ニュース@ElektraInitiative / elektradevelopers：

• 前述のように、ほぼ_すべて_はPRから、および/またはビルドボタンのみを押すことでビルドできるようになりました
• トリガーフレーズは常にelektra-プレフィックスのないジョブ名です。 （例：elektra-clang：jenkins build clang please）レガシーの理由で、 jenkins build pleaseやその他の古いフレーズを変更しませんjenkins build please
• githubビルドステータスメッセージは常に正確にビルドジョブ名です

ありがとう、よくやった！ doc / GIT.mdを更新して、現在どのフレーズが機能しているかを全員に知らせてください。

（ @mentionが単一のメッセージに対してのみ機能し、ここに書き込んだすべてのメッセージを全員が読むわけではないことを願っています）

Mac OS X for xcode6.1ビルドが壊れているようです：
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

私はそのために再構築をトリガーしましたが、一時的なトラビスの失敗のように思えます。

PR用にビルドを再トリガーする方法を文書化できますか？ 私はそれが可能だとは知りませんでした。

上記のリンクを使用して、travis-ci.orgに直接アクセスしてください。

これがドキュメントに値するものかどうかは疑わしいですが、それでも可能です。
ビルドは、gitチェックアウトのためだけにまだ機能していません。 これは私たちのせいではないと思います。

ああ。 そもそもビルドがトリガー/開始される前にマージしたと思います。
以前に成功した他の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..

誰かがコンテナを止めたようです。 再開しました。

ところで、明日の朝から、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

jenkinsの更新または@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は（ほとんどのビルドの中で）再び不安定に動作しますが、ウォークエラーはいくつかのより単純なビルドジョブで持続します。 ブランチはまだどこかで利用できるようです。おそらくビルドサーバーのキャッシュにありますか？

 > 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"

さらに、1つのグローバルリポジトリを更新するビルドジョブを作成する必要があります。 個々のタスクは上記を参照してください。

グローバルレポは間違いなく帯域幅の削減に役立つ可能性があります。 ソース内でスクリプトをビルドすることも良い考えかもしれません、少なくともそれらはgitによって追跡されるでしょう。

私は小道のスペースのファンではありませんが、確かに。

passwdの高速ビルドが壊れていますか？

高速ビルドジョブは煩わしいです。ビルドごとにkdberrors.hを削除して、よりスムーズに機能するかどうかを確認します。 長期的には、＃730の@manuelm提案が最善の解決策です。ソースがどのように更新されたかを確認し、これに基づいて適切な測定を行う必要があります。

＃894も高速ビルドを修正すると思います。kdberrors.hを削除する行にコメントします。

html docジョブなど、一部のジョブが壊れています。

@mpranjそれを見る時間はありますか？

@ markus2330完了。 残りのビルドの失敗は、ビルドシステムに関連していないようです。

@mpranjありがとうございます！ それを修正するために何をしましたか？ サーバーの問題を構築するための解決策もここに集めておくと便利だと思います。

「ソースコード管理」>「Git」で変更しました
「ブランチ指定子」の値「**」から「$ {sha1}」

これは私たちが他の仕事でも使用しているものです。 これにより、ボタン（ブランチのデフォルトはマスター）またはgithub PRビルダー（コミットのsha1）でビルドをトリガーできます。

ENV変数「sha1」を「master」に一度設定したことを思い出します。 今は行方不明のようですが、ジョブは正常に機能するので、無視しましょう。

オブジェクトライブラリをより頻繁に使用することで、ビルドをさらに高速化できると思います。 多くのオブジェクトファイルは複数回コンパイルされます。 オブジェクトライブラリを使用するすべての場所でコンパイルフラグが同じであることを確認するだけで済みますが、これは簡単に可能になるはずです。

それが大きな違いを生む可能性がある例は、私の意見ではKDBです。

@Namoshekビルドシステム全般についてではなく、ビルド_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からビルドをトリガーしました

どちらのビルドもツリーをチェックアウトしてビルドを開始することができました。
だから：私はそれを再現することはできません。

1つのアイデア：PRがあったときにtravisに問題があり、travisがクローンを作成する前にそれをマージします。 elektra-multiconfig-gcc47-cmake-optionsでビルドに約3時間かかるため、同様のことが起こった可能性があります。

アーティファクトをdoc.libelektra.orgにプッシュすると再び機能し、Jenkinsとプラグインがアップグレードされました。

私は、新しいビルドサーバーURL更新https://build.libelektra.orgをgithubののウェブフックに。 したがって、次のPRが再び構築されることを願っています。

ジェンキンスの家はほぼ満員です。 また、PRを構築していないようです。

ジェンキンスの家はほぼ満員です。

サイズを変更していただきありがとうございます。

また、PRを構築していないようです。

ここで何が間違っているのか分かりますか？ 手動トリガーは機能しているようですか？

ドキュメントをdoc.libelektraに公開します。 org：12025はビルドに失敗しました。 （build-homepageエージェントで）sshサーバーを再起動しましたが、再び機能するようです。

* .libelektra.orgのvserverに到達できないようです。 ヘッツナーで報告しました。

コンテナからのネットワーク接続をシャットダウンする理由は、libelektra.orgが危険にさらされているためです。 詳細については、＃1505を参照してください。

ストレッチ用のgit-build-packageを追加できれば素晴らしいと思います。ストレッチ用にビルドされたdebianパッケージが必要な場所がどんどん増えています。

@BernhardDennerあなたはトップの投稿を見ましたか？ 簡単にできることはありますか？ 将来ビルドサーバージョブを改善するときに@mpranjが考慮する必要があることはありますか？

@sanssecoursの要求に@KurtMiに追加し

jenkinsはgcc-configure-debian-optimizationsをビルドしてください

@KurtMiビルドジョブの機能を変更する必要がある場合は、scripts / configure-debian-optimizationsを変更するだけです。

@sanssecoursは、ビルドサーバーにもアクセスできるようになりました。

ところで。 とにかく他のジョブに取って代わられた場合は、ジョブをキャンセルできます（現在、負荷が大きい）。 アクティブなPRのジョブを中止しないように注意してください。そうしないと、PRが緑色になりません。 （「jenkinsbuild ... please」というフレーズで再起動しない限り。）

@sanssecours Jenkinsが再起動されました（2回目）。 新しいプラグインをインストールする場合は、ここに文書化してください。 （更新を文書化する必要はありません）。

再起動のリクエストもここで行うことができます。

「Quietperiod」を2から5に変更して、複数のPRをマージしたり、繰り返し再構築せずに異なるコミットをプッシュしたりする時間を増やしました。

さらに、ビルドのタイムアウトについて説明している問題＃1689を開きました（エラーメッセージが長いため、ここでは追加しませんでした）。

また、上記の新しいセクション「廃止された/無関係な問題[理由]：」で、いくつかの廃止されたタスクを移動しました。

ビルドサーバーのプラグインを更新しました。 うまくいけば、アップデートによってPR＃1698とPR＃1692の問題が修正されます。

@ markus2330ビルドサーバーを再起動していただけますか？

Jenkinsを2.73.2から2.73.3にアップグレードし、Jenkinsを再起動しました。

うまくいけば、アップデートによってPR＃1698とPR＃1692の問題が修正されます。

これらの2つのPRに関係のない一般的な問題である可能性がありますか？ うまくいけば、それは今修正されています。

JENKINS_HOMEがほぼ満杯のようです😢。

@markus2330👋お願いします

• ホームディレクトリをクリーンアップするか、その方法を教えてください。
• Jenkinsとすべての古いプラグインを更新しますか？

私にpingしてくれてありがとう！

プラグインには「任意のファイル読み取りの脆弱性」、つまり「スクリプトセキュリティプラグイン1.35」があったようです。

すべてのプラグインをアップグレードし、jenkinsも2.73.3から2.89.1にアップグレードしました。

さらに、ディスクのサイズを20GBから50GBに変更しました。

すぐにサーバーを再起動する必要があります。ライブラリのアップグレードの影響を受ける可能性のある再起動されていないプロセスがいくつかありますが、現時点では安全ではない可能性があります（ただし、jenkinsとは関係ありません）。 @BernhardDenner再起動を実行できますか（何かが起動しない場合は修正を実行できますか）？

これらのアップグレード中に私が壊したものは何でも報告することを躊躇しないでください。

サーバーの負荷は20で、ほとんど応答しませんでした。 「jenkinsbuildall please」に注意する必要があり、長期的にはエージェントをメインサーバーから移動する必要があります。

Jenkins 2.89.2にアップグレードし、サーバーを再起動しました。 すべてが再び稼働し始めたら報告します。

「サーバーのホストキーが検証者のコールバックによって受け入れられませんでした」というエラーで、すべてのエージェントが切断されたようです。

@BernhardDenner puppet applyが実行されているのを見ましたが、現在セットアップに取り組んでいますか？

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ビルドサーバーキューから判断すると、これでうまくいくようです

しかし、ryzenがそれらの仕事を処理していないように見えることに気づきました。 これは、タグに一致するジョブのみを処理するように構成されており、multiconfigビルドではそれらのタグが一見適切に設定されていないように見えるためだと思います。 したがって、ryzenに可能な限りすべてを実行させるか、ビルドジョブにより多くのタグを設定する必要があります。 ryzenはタグがまったく設定されていないジョブを処理していないようです。

gcc-stable-multiconfigで機能した後、さらにgcc-stableに適用します

ありがとうございました！

しかし、ryzenがそれらの仕事を処理していないように見えることに気づきました。

いいえ、そうではありませんが、すでに他の多くのジョブを実行しています。 しかし、多分私たちはそうするためにv2を作ることができますか？

さらにgcc-stableに適用します

終わり

しかし、多分私たちはそうするためにv2を作ることができますか？

v2を構成しましたが、＃1806 PRがマージされるのを待つだけなので、1つより多くのビルドを許可できます。 SMTも利用するために-j2を使用した8コアなので、8つのジョブで問題ないと思いましたか？

v2がクラッシュまたは再起動した場合にbuild-v2コンテナーを再起動するには、単に。と入力します。 これは、コンテナがすでにビルドされている場合にのみ実行できることに注意してください。これらの手順については、doc / docker / jenkinsnode /README.mdに従ってください。 次に、このコマンドを使用して、コンテナーが作成されたが停止した後に再起動します。

docker start build-v2

また、新しいビルドノードのssh接続をv2からa7経由で外部に転送するために、a7に次のsshトンネルを設定しました（dockerコンテナーはそのsshポートをv2の22222にマップします）。

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

さらに、Dockerコンテナのパブリック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>

最初の2つだけをコピーするので、キーアルゴリズムとキー自体は、最後にこのユーザー情報をsshキーのjenkinsでのryzen-v2の構成にコピーしないでください。

v2がダウンしているので、管理者に通知しました。 それは非常に奇妙です。a7とv2はどちらも完全に新しいハードウェアであり、インシデントは非常に頻繁に発生します。

v2が戻ってきたようで、そこでビルドコンテナを再起動しました。 うまくいけば、ビルドが再び高速になります。 さらに、タイプチェッカー用に安定したhaskellビルドが必要なため、「jenkins buildallplease」にelektra-haskellを追加しました。テストは良い追加です。

さらに、ここで、v2の新しいボトルネックのように見えるmmビルドを処理する別のビルドノードを追加で作成することに注意してください。

最後に、 @ markus2330これは通常のテスト/testscr_check_bashisms.sh 1つであるため、ポイントランバシズムチェッカーはすでに実行されていると思います。

ラベルdebian-jessie-homepage||homepageとビルドエージェントdebian-wheezy-mrすべてのノードは現在オフラインです。 ビルドエージェントの再起動は機能しません。 SSHまたはこれらのノードへの物理アクセスを持っている人がこの問題を調査できれば本当に素晴らしいでしょう。

vserverを再起動しましたが、jenkins内でエージェントを再起動しても、「リクエストに有効なクラムが含まれていません」というエラーが表示されませんでした。 @BernhardDennerアイデアはありますか？

v2もダウンしているようです。 したがって、3つの非機能エージェントがあります😢

v2が戻ってきましたが、なぜ常にダウンするのでしょうか。 それは私たちのビルドプロセスに関連している可能性がありますか？

「有効なクラムがない」に関しては、v2でエージェントを再起動しようとしたときにもそれがわかりましたが、単に再試行したときには機能しました。

v2が戻ってきましたが、なぜ常にダウンするのでしょうか。 それは私たちのビルドプロセスに関連している可能性がありますか？

カーネル/ハードウェアの障害のようです（コンピューターがハングしたときにsysreqでさえ機能しません）。 私たちの使用法はエラーを引き起こす可能性があります。 コンピューターは数か月間エラーなしで実行されていましたが、使用してからすでに3回クラッシュしました。

カーネルをアップグレードし、Xサーバーをパージしました。

「有効なクラムがない」に関しては、v2でエージェントを再起動しようとしたときにもそれがわかりましたが、単に再試行したときには機能しました。

ありがとうございました！ これで、ホームページエージェントを再開できました。

さらに、エージェントdebian-jessie-minimalとそのビルドジョブを無効にしました。 最小限のジョブ用にDockerコンテナーを作成する必要があります。これをタスクとして追加しました。

昨日驚いたように、コミュニティサーバーがクラッシュし、間違ったARPキャッシュがIPを他のサーバーにリダイレクトしたためにダウンしました。 再起動後、すべてが再び機能しましたが、レイド同期はまだ進行中です。 （負荷が高いため、非常に遅い場合があります。）

コミュニティサーバーの負荷はほぼ一定で、10です。現時点では13.20 11.299.35です。 コミュニティサーバーで直接実行されているジョブを減らし、負荷をv1に移動する必要があります。 ボランティアはいますか？

Jenkinsが2.89.2から2.89.4にアップグレードされています。 残念ながら、変更ログを確認する簡単な方法が見つかりませんでした（ 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：

しかし、少なくともa7は現在安定しているようです。

clang-format-5.0をa7とストレッチノード（debian-stretch-mr）にインストールしました。

次のPRについては、clang-format-5.0に従って再フォーマットしてください。

https://build.libelektra.org/jenkins/job/elektra-clang-asan/が一時的に無効になりました。

現在、v2を調査中です。 UEFIは6.6.17からです。 クラッシュは常に週末に発生したようですが、そのときは負荷が高いのではないでしょうか。 v1のセットアップをv2に複製してみます。

v1とv2は、同じカーネルで稼働しています。

@ e1528532 sshブリッジが起動せず、doc / docker / jenkinsnode / README.mdのコマンドが「コンテキストを準備できません：Dockerfileパスのシンボリックリンクを評価できません：lstat / root / Dockerfile：そのようなファイルまたはディレクトリがありません」で失敗するようです"そして"画像 'buildelektra- stretch：latest 'をローカルで見つけることができません "。 これは、現時点ではv2に到達できないことを意味します。

@ markus2330の書き込み：問題を＃1829に移動

ビルドサーバーの最新の更新の1つが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ブリッジがありません）。

Elektra0.8.22がついにリリースされました。 ウェブサイトが構築されたら、＃676へのリンクを追加します。ウェブサイトの構築には1時間以上かかります。 たぶん、ホームページビルドをより高速なマシンに移動し、結果のWebサイトをその場所にコピーするだけで済みます。

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は再びスムーズに実行されているようです。

@ e1528532sshトンネルはまだ機能していないようです。 a7を再起動した後でも、v2に接続することはできません。

したがって、他のものを配置することを検討する前に、まずv2を安定させる必要があります。

主なダウンタイムはsshブリッジが原因でした。 v2に問題が発生した場合、通常は1日以内に再起動されました。
Xサーバーの残りの部分を削除したので、v2も安定していることを願っています。 a7の場合、これがトリックのようでした（かなり長い間再起動は必要ありませんでした）。 ただし、v2（sshブリッジが必要）に負荷がかかっていない場合は、安定しているかどうかはわかりません。

ハードウェア（再起動）とソフトウェア（Jenkinsのアップグレード）に関する議論を分割するのはどうですか？

a7とv2の間にネットワーク接続の問題があるようです。 v2は稼働していますが、それでも「ホストへのルートがありません」というメッセージが表示されます。 今日は直せないようです。

GNOMEの削除により、network-managerも削除されたため、v2のネットワークがダウンしました。 ネットワークを修正し（/ etc / network / interfacesを使用）、最新のBIOS / UEFIにアップグレードしました。 したがって、すべてが安定していることを願っています。

ところで。 sshブリッジを介して使用できるハードウェアがもう1つあります...（PCS）

sshトンネルはまだ機能していないようです。 a7を再起動した後でも、v2に接続することはできません。

はい、これは自動化されていません。 今、私はすべての世話をしました。 マシンが再起動すると、Dockerコンテナが自動的に再起動するはずです。 少なくとも私は「常に」によるに--restartフラグを設定しているhttps://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode ＃37618747

さらに、a7とv2の両方にパスワードが設定されていない「ssh-tunnel-a7-v2」という新しいユーザーを作成しました（そのため、そのユーザーのパスワード認証を無効にしました）。 a7でユーザーのssh証明書を作成し、その公開鍵をv2の既知のホストに追加しました。 次に、systemdサービスを/etc/systemd/system/ssh-tunnel-a7-v2.service追加しました。これにより、 https： //gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file-ssh-tunnel-serviceに従ってsshトンネルがsystemdサービスとして自動的に開きます。 したがって、サーバーが再起動されたとき、または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によって行うことができます。 ルーカスに何をすべきか知っているか聞いてみます。

やあ、

@sanssecoursが指摘したように、ryzen v2にはdockerがインストールされていませんが、
test-dockerの実行では、ノードにdockerタグが必要です。

考えられる解決策は、ノードにdockerをインストールするか、jenkinsのノードからタグを削除することです。

考えられる解決策は、ノードにdockerをインストールするか、jenkinsのノードからタグを削除することです。

問題の解決策を提供していただきありがとうございます。 ryzen v2からdockerタグを削除しました。 私が知る限り、すべてが今はうまくいくようです。

'ryzen v2'ノードの説明を更新して、実際には 'v2で実行されているdockerコンテナーのみ'であることを反映しました。 したがって、v2にインストールされているのにdockerが利用できなかったのはなぜですか。

また、ビルドデータの視覚化を容易にするプラグインをjenkinsに追加しました（各ビルドをクリックする必要はありません）

v2が再びダウンしている、と報告しました。

v2を再起動しましたが、エージェントを再接続できませんでした。

少なくとも、クラッシュの前に何が起こったかについてのエラーメッセージがついに得られました（もちろん、エラーメッセージがクラッシュと関係があるという保証はありません）：

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

奇妙なことに、再起動機構が機能したようです。sshトンネルとdockerノードの両方が再起動され、a7.complang.tuwien.ac.at -p 22222に接続できます。これは、すべてが開いている必要があることを意味します。 しかし、どういうわけか、ジェンキンスは何らかの理由で無限のスピニングホイールを見せてくれます。タイムアウトも何もありません。

以前と同じように、手動のsshブリッジを試しました。 同じように、Dockerコンテナをもう一度再起動しました。 正直なところ、エラーメッセージが表示されずに今何が正確に間違っているのかわかりません。私が見つけた唯一のことは、明らかに同様のバグ（スピニングホイールはありますがメッセージはありません）を持っているが、マスタージェンキンス全体を再起動する以外に解決策がない人です。ノード（私は試していません）： https ：

編集：私は提案された回避策の1つを試しました（ホスト名の構成を存在しないものにリセットし、再接続すると、jenkinsはホスト名が間違っていることに気付き、実際のホスト名に戻って、それ以上の手間をかけずに突然機能しました）。 だから私はこのエラーが私の再起動セットアップで何かの代わりに起こったと思いますが、次のクラッシュがそれで確実になるのを待ちましょう;）

@ markus2330すでにこれを自分で見つけたにhttps ： //bugzilla.kernel.org/show_bug.cgi？id = 196683 、いくつかの提案がありますそのための回避策

ビルドサーバーryzenがリポジトリに接続できないようです：

https://github.com/ElektraInitiative/libelektra.gitからのフェッチに失敗しました

。

DNS設定が再びぶら下がっていました。 理由がよくわからないので
現在の方法でセットアップするネームサーバーの設定のみを復元し、
Dockerビルドジョブを再開しました。

夜05時03分に2018年3月12日、ルネ・シュバイガーの[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は安定しているようです。 したがって、1つのオプションは、a7でもネットワークマネージャーをアンインストールすることです。 （そして/ etc / network / interfacesを使用してください）v2とa7の設定が異なる理由はありません。それは、管理がお粗末なためだけです。

理想的には（長期的には）、Puppetを使用して両方を管理します。

https://bugzilla.kernel.org/show_bug.cgi?id=196683 、そのためのいくつかの推奨される回避策があります

C6を無効にする必要がありますが、調査を続行します。

新しいビルドエージェント「ryzenv2docker」では、 「debian-stable-mm」のようにD-Busデーモンが実行されていないようです。

誰かがそれをインストール/開始するか、どのスクリプトがmulticonfig-gcc47-cmake-optionsビルドを構成するかを教えて、スニペットを追加して開始されていることを確認できますか？

@ markus2330 ifupdownとnetworkmanagerの両方が有効になっているので、両方ともお互いの髪の毛に入り込んでいるのではないかと思います。 2つのうちの1つを無効にすることは確かに役立ちます。

さて、v2との一貫性を保つために、a7のgnomeとnetwork-managerを削除しました。

新しいビルドエージェント「ryzenv2docker」では、「debian-stable-mm」のようにD-Busデーモンが実行されていないようです。

ビルドエージェントはDockerコンテナー内に存在し、 @ ingwinluまたは

ありがとうございました。 かなり簡単なはずです。 次のコマンドを使用して、Dockerコンテナー（ docs/docker/Dockerfileから作成されたUbuntu 17.10 artful）で起動します。

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

ビルドサーバーryzenはリポジトリに再度

すみません、私のせいです。 network-managerを停止するだけで、システムが壊れたようです。

今すぐ修正する必要があります。 それ以上の問題を報告することを躊躇しないでください。

@ markus2330は、次の再起動時に再び壊れたと確信しています

私は自由に/ etc / network / interfacesファイルをやり直しました（そしてインターフェースの構成を/etc/network/interfaces.dに移動しました）
ネットワークマネージャーの削除と組み合わせると、うまくいけば安定した状態に保たれるはずです

構成を確認し、再起動をトリガーして、機能するかどうかを確認してください

@ingwinlu修正していただきありがとうございます、再起動はうまく

削除したパッケージが多すぎることがわかったので、Java（openjdk 9ヘッドレスおよびdefault-jre）を再度インストールしました：smile：

@ingwinludbusをv2エージェントで実行して

@ markus2330ビルド環境を進める方法

その後、ビルドパイプラインをセットアップして、リポジトリにチェックインされたDockerfileからイメージ自体をビルドし、テストに必要なさまざまな環境を提供できます。

dbus対応のDockerイメージに到達したら、ロールアウトを優先することはできますが、必要がなければすぐに関係のない作業はしたくありません。

はい、それは理にかなっています！

v2の長期的な目標は、他のDockerコンテナー（Elektra用ではない）と共有する必要があるため、他のDockerコンテナーに影響を与えないようにすべてのパーツを仮想化するとよいでしょう。 （おそらく再帰的なdockerまたはXen？）a7が同じセットアップを持つために、同じことを行うことができます/すべきです。

引き続きマシンに直接アクセスできますが、JenkinsがDockerマシンを強制終了するリスクを減らす必要があります。

一部のエージェントでは、すでにPuppetが設定されています。 それをバイパスしないか、それ以上にすれば素晴らしいでしょう。このセットアップをa7とv2に拡張してください。 @BernhardDennerがあなたにそれについてのより多くの情報をすぐに与えることができることを願っています。

ビルドサーバーが再びダウンしました🙌。

ちなみに、このトピックはこの問題を購読しているすべての人にとって興味深いものではない可能性があるため、ビルドサーバーのステータスに関するディスカッションをGitHubチームのディスカッションに移動することができます。

はい、ビルドサーバーを含むサーバー全体がダウンしています：cry：そしてv2も（独立して）ダウンしています。 v2を再起動し、UEFIのC-Statesオプションを変更しました。 しかし、私たちのサーバーには大きな問題があるようです。 うまくいけば、より多くのメモリを備えたより良いハードウェアに置き換えられます：crossed_fingers：

GitHubチームのディスカッション

GitHubチームのディスカッションに何かを書いた場合、ElektraDevelopersの全員に通知されませんか？ この号では、誰もが購読するかどうかを決めることができます。

私にとってまだ未解決の質問は、この問題をハードウェア関連とジェンキンス関連の2つの問題に分割する必要があるかどうかです。

GitHubチームのディスカッションに何かを書いた場合、ElektraDevelopersの全員に通知されませんか？

私の知る限りでは、そうです。

この号では、誰もが購読するかどうかを決めることができます。

これはチームディスカッションにも当てはまります。

ビルドサーバーが再び起動します。 変更された設定：

• キューに大量のビルドがある場合にガベージコレクションの量を減らすためのxmsおよびxmx設定
• scmポーリングを使用していることに気づきました。 サーバーが現在取得しているスパイクを少し減らすために、ポーラーを一度にグローバルに4つの同時ポーリングに調整しました。

編集：

* webuiにアクセスするときに読み取られる複数のソースに応じて、すべてのパイプラインでビルド数を30に維持するように設定します。したがって、古いビルドが多数あると、リクエストが遅くなります。

Jenkinsをver。に更新します。 2.107.1

• jenkinswarファイルを更新します
• プラグインの更新が許可されないため、 Use browser for metadata downloadプラグインのセキュリティ設定を無効にします
• プラグインを利用可能な最新バージョンに更新します

編集2018-03-18：

• mmで実行されているすべてのノードに2番目のエグゼキュータを追加しました

* mrで実行されているすべてのエージェントの優先順位を下げました

マスターは、負荷がかかった状態で、はるかに応答性が高くなるはずです。 すべてをビルドするのは、以前の4時間以上と比べて2時間に近いはずです。

編集2018-03-24：
遅れてすみません、忙しい週...

• リポジトリにあるJenkinsfileを実行する新しいジョブ（elektra-jenkinsfile）をjenkinsserverに追加しました（存在すると）

編集2018-03-28：

• トンネルユニットファイルを再作成しました。環境ファイルを解析するため、複数のターゲットを指すように調整できます。
• Dockerを実行できるスレーブとしてv2サーバーを追加しました
  
  
  
  • v2にjenkinsユーザーを追加しました
  
  
  • v2にopenjdk-9をインストールしました
  
  

編集2018-03-29：

• jenkinsマスターの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はインストールされておらず、Dockerホストとしてのみ機能する必要があります。 追加のフラグを削除します。
//編集：実行する必要があります。 うまくいけばそれで十分でした
// EDIT2：テストの実行に必要なビルドイメージが明らかに見つからないため、今のところtest-dockerも無効にしました。

しかし、それが実際にそれが構築できるものを手に入れれば、物事は速いです
// EDIT3：docker-prefabタグのあるノードでのみ実行するようにテストドッカーを有効にし、そのタグをryzenに渡しました

悲しいことに、問題は当初の予想よりも大きいようです。

一部のジョブでは、ノードがハードコードされています。 一部のタグは古くなっています（jessieノードで安定しています）。 一部のジョブは正しいノードを必要とせず、正しいノードでのみ実行されました。これは、以前に1回実行され、正常にビルドされたためです。

新しいノード（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午前Doを、29 MARZ 2018、21時24分：

@ingwinluhttps ：//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を返しました：
stdout：
stderr：
*あなたが誰であるか教えてください。

走る

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

アカウントのデフォルトIDを設定します。
--globalを省略して、このリポジトリにのみIDを設定します。

致命的：空の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 Saを、31 MARZ 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分ごとにa7にポップアップしています：

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)

これらが、a7のダウンタイムの理由であるだけでなく、a7の遅延での奇妙なビルド動作の一部である可能性があります。

make run_memcheck介して実行されたため、 elektra-ini-mergerequests valgrindセクションを無効にしました

これらは10分ごとにa7にポップアップしています

はい、私たちはすでにそれらを見ました。 コンピュータを購入したとき、誰かが実際に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

再びa7があります。

より生産的なフロントで：私は青い海のフロントエンドをジェンキンスにインストールしました。 プレビュー

再びa7があります。

その本当にイライラします。 マシンを再起動し、エージェントを再接続しました。 明日、管理者にRAMの交換を依頼するので、明日はダウンタイムが発生する可能性があります。

より生産的なフロントで：私は青い海のフロントエンドをジェンキンスにインストールしました。 プレビュー

素晴らしく見える！ 次の会議で見せてもらえますか？

私たちの管理者はすでに週末にいます。 a7を再起動し、BIOS / UEFIを工場出荷時のデフォルトにリセットします。 エラーが週末に続く場合、彼はうまくいけばRAMを交換します。

編集：ビルドジョブが実行されていなかったため、ビルドジョブがキャンセルされませんでした。

編集：すべてが再びアップしています。 これまでのところ、メモリエラーはありません。

ずっと良く見えます。 誰かがライナスの技術的なヒントをあまりにも多く見て、サーバーをオーバークロックしましたか？

申し訳ありませんが、しばらくの間Jenkinsを停止する必要がありました。 サーバーの負荷は20で、必要なことはもう不可能でした（1時間以上の待機時間、それからあきらめてJenkinsを停止しました）。

開始されていないビルドジョブでもRAMが必要になる可能性はありますか？ （キューリストが非常に長かった）それ以外の場合、ローカルビルドジョブがこれらの問題の最良の候補です。 （3つのローカルビルドジョブが実行されていました）

@ingwinlu理想的には、そのサーバー上に何も構築しません。 さらに、サーバーの負荷に応じてビルドジョブを作成できますか？ （負荷が5を超えるサーバーでジョブを開始しないでください？）。

私はすべてをやり直しましたが、そのための迅速な解決策が見つかることを願っています。

Jenkinsシステム設定でVERSIONとCMPVERSIONをポンピングしました。

@ingwinluJenkinsfile内にもこれらの設定があれば素晴らしいと思います。

@ markus2330 Jenkinsfileでこれを実現する方法の例については、

しばらくして失敗し、＃1882のおかげで最終的にビルドシステムに表示されたため、次のターゲットからmake run_memcheckを削除しました

• 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バージョンを使用するのと同じようにテストしません...

トラヴィスが古い使用しているが、私は、同意clang 5.0.0で、クランのバージョンをelektra-clang-asan古代である（ 3.8.1 ）。 このような古いコンパイラのASAN対応ビルドジョブの値がわかりません。

「elektra-clang-asan」で失敗した「testlib_notification」テスト用に＃1919を作成しました。

すべてのmrエージェントを無効にしてすべてのビルドをテストしたところ、マスターは完全に応答しましたが、すべてのmrエージェントを有効にしてすべてのビルドで実際に一部のビルドがタイムアウトしました。 したがって、すべてのmrエージェントを取り除くことができれば＃1866は間違いなく改善を提供します（コンテナ化できないので気まぐれです）

さらなるテストは、それがほとんどホームページ構築の仕事だけであることを示しています。 今のところbuild allから削除したので、明示的にのみ実行されます。

コンテナ化されたソリューションに置き換えられます。

v2は最新のBIOSで再びオンラインになります。

ここでsegfaultを報告してください（CPUにバグがある可能性があります）。

a7がダウンしているようですか？

午前11時10分に2018年5月4日、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を含む）に対する反応もまったくありませんでした。 ハードリセットだけが役に立ちました。

問題が何であるかについて何か考えがあれば、教えてください。

残念ながら、a7には永続的なジャーナルが設定されていないため、ログはありません

a7とv2が再び利用可能になるのはいつですか？

ああ、私は彼らがダウンしていることを知りませんでした。 管理者に再起動を依頼します。再起動できない場合は、17：00頃に再起動します。

編集：彼は今すぐそれらをリセットすると言った。

編集：両方とも再び稼働しています。

今日、a7とv2を手動で再起動しました。 v2にはもう到達できないようです。 実際に動いていただけませんか？

//編集：両方のマシンのネットワーク構成を修正することで解決

どうやらa7が再びダウンしました。

はい、彼女を再起動します。 そうしないと、このリリースが完了しません。

原因の兆候はありますか？ ネットワークの問題だけですか、それともマシンが再び応答しなくなったのですか？

これですべてが稼働しているはずです。

私はちょうどいいタイミングでそれを手に入れました、それが最終的に完全に凍結するまでいくつかのログがありました。

ログは次のとおりです。

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

それは何でもかまいません。 欠陥のあるryzencpuから悪いpsuへ:(

午後02時33分に2018年5月12日、markus2330 [email protected]は書きました：

これですべてが稼働しているはずです。

私はちょうどいいタイミングでそれを手に入れました、それが最終的にそれまでいくつかのログがありました
完全に凍結しました。

ログは次のとおりです。

情報：rcu_schedがCPU /タスクでストールを検出しました：
..。
rcu_schedkthreadは7770jiffiesに飢えています
ウォッチドッグ：バグソフトロックアップ-CPU＃2が22秒間スタックしました！ [docker-gen]
...（多くの繰り返し）
NMIウォッチドッグ：ウォッチドッグがCPU2でハードロックアップを検出しました

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
。

＃1993について

@ingwinlu現在成功しない場合は、ジョブを無効にしてください（または、少なくともデフォルトで、または「jenkins build

Jenkinsのアクションが原因で失敗した場合は、ジョブを再開するとよいでしょう：heart：ここ＃160でそう言っても大丈夫です。

v2が再び稼働し、新しいCPUが搭載されました。

ストレステストのためにたくさんの仕事を提出してください：smile：

a7が再びダウンしているようです。

ありがとう、すべてが再び起きています。

a7を再起動しました。

1時間ごとにa7をリセットする回路があると、可用性が向上する可能性があります。

いつa7が再びオンラインに戻ると期待できますか？

a7がオンラインに戻りました

v2がオンラインに戻りました

v2の電源は約1時間で交換されます。

@ingwinluエージェントを無効にして、後で再度有効にできますか？ （現在作業中の場合。）

v2エージェントは今のところ無効になっています

v2が再び実行されています。 新しい電源があります。 機械のストレステストのために多くの仕事を提出してください。

jenkinsプラグインを更新しました。 結果として再起動すると、古いjenkinsノードが部分的に復元され（名前が変更される前）、gitリポジトリが壊れたため、どこでもビルドが壊れました。

念のため、影響を受けたリポジトリをクリーンアップし、キャッシュされたDockerコンテナをクリーンアップしました。

a7は再びダウンしているため、Dockerベースのビルドは再び利用できません。

また、セキュリティ制限に違反しているため、アップデートをxunitにロールバックしています。

a7を再起動し、すべてのエージェントを再接続しました。

a7が再びダウンしているため、dockerビルドは使用できません。

サーバーを再起動し、エージェントを再接続しました。

a7を置き換えることが最善の方法だと思います。＃2020を参照してください。

私は再びダウンしていると思います、私の最新のコミットは結果としてa7-debian-stretchに連絡できません：java.lang.InterruptedException

@ e1528532ここに書いてくれてありがとう！ 必要に応じて、＃2020に投票することもできます

a7を再起動し、エージェントを再接続しました。
週末に問題が発生しないように頑張りましょう。

a7が再びダウンしました：cry：週末を通してほぼ機能したのは驚きです。 今週の稼働時間の記録かもしれません。 それにもかかわらず、＃2020は多くのコメントを受け取りませんでした。

私はa7を再起動し（sysctlに反応しました）、他の誰かがjenkinsを開始しました。 すべてが再び稼働しています。

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からping可能です...

EDIT3：a7もダウンしています。

報告ありがとうございます！ a7とv2を再起動しました。 ＃2020を再考する必要があります。

私はv2が再びダウンしていると思います：

v2-debian-stretchに接続できません：java.lang.InterruptedException

v2ではすべてが正常でしたが、a7は再びダウンしました。 すべてのエージェントが再びオンラインになりました。

v2は再び半応答しないようです。 a7からping可能ですが、sshアクションはまったくありません。 症状だけからのbtrfsの問題である必要があります。 週末に家に帰る前にすべてを再起動できますか？

@ingwinluありがとうございます。 @ wahtとv2を正常に再起動しましたが、エージェントに接続できません（「接続が拒否されました（接続が拒否されました）」）。 ここで何が悪いのか考えてみませんか？ （インタラクティブなsshログインは機能します）

sshは、ブリッジ経由で接続していない場合にのみ機能しました。

ブリッジングサービスを再起動した後、接続を確立できました。

sshトンネルが奇妙な未定義の状態になり、自殺しなかったようです。 なぜそれ自体が自殺しなかったのかわからない（serveraliveintervalがオンになっている）。

また、fsが破損し、それらのすべてのビルドジョブが失敗したため、v2のすべてのワークスペースを手動でクリーンアウトする必要がありました。

a7がダウンしているようです。 月曜日までに再起動できるかどうかわかりません。

a7とv2を再起動しました。 （v2は、v2へのsshブリッジを作成できないというエラーメッセージがa7にあったためです。ただし、v2の再起動後も同じエラーメッセージが発生しました。それでも、sshブリッジは機能しているようです。依存関係（ネットワーク？）が欠落している可能性があります。 a7の起動スクリプト？）

たぶん、a7の起動スクリプトにいくつかの依存関係（ネットワーク？）がありません

いいえ、ありません。

v2へのsshブリッジを作成することはできません

この動作は、v2カーネルが応答しなくなったときに発生すると思います（したがって、着信ネットワーク接続を確立できません）。 過去に、v2でのbtrfsエラーを示すログについて言及しました。

後でCPUを交換するために、ビルドサーバーをシャットダウンする準備をします。

a7とv2が再び戻ってきました（新しいCPUを搭載したa7、ルートファイルシステムがチェックされたv2）

日中は（一貫したビルドで）維持されていましたが、a7が再びダウンしたようです。

はい、明日の朝に再開します。

＃2020についてもう一度話し合う必要があります。

a7を再起動しました。 これもCPUのハングでした。

a7が再びダウンしています。

ありがとう、再起動しました。 すべてのエージェントが再びオンラインになります。

一部のDebianノードがダウンしているように見えるため、いくつかのPRSは、テストの実行が開始されるのをすでに長い間待っています。 それは意図されていますか？

一部のDebianノードがダウンしているように見えるため、いくつかのPRSは、テストの実行が開始されるのをすでに長い間待っています。 それは意図されていますか？

mm-debian-unstableノードでのアップグレード中に、マシンが応答しなくなり、それ以降、マシンに接続できなくなりました。 所有者が私たちの電子メールに応答していないので、それはおそらく永遠に消えてしまうでしょう。

かなりの量のビルドジョブを新しいシステムに移植しましたが、すでに不足しているのは、現在キューにぶら下がっているジョブです。

影響を受けたジョブを無効にし、それらを置換+ドキュメントから削除するようにマークしました

@ingwinluこれを世話してくれてありがとう！

誰かがリゾルバーで作業したい場合は、xdgテストを再読み込みすることが非常に重要です。 ここの一番上の投稿に追加しました。 上記のチェックリストですでに達成したことを更新できますか？

今回はv2が幸運な勝者です。

@ markus2330トップポストをクリーンアップしました。

クリーンアップありがとうございます！ 明日の朝、v2（そしておそらくa7、見てみましょう）を再起動します。

再起動しました。 反応もメッセージもありませんでした。 ＃2020を参照

a7とv2を再起動してください。

a7を再起動しました。 v2で問題は見つかりませんでしたが、とにかく再起動する必要がありますか？

i7は192.168.173.96で利用可能になりました。a7経由でブリッジを作成してください。

マシン上にssh-tunnel-a7-v2ユーザーを作成するか、アカウントを作成する必要があります。

libelektraビルドジョブに役立つビルドスレーブi7-debian-stretchを追加しました。

v2-docker-buildelektra-stretch (offline)は、ビルドジョブがスケジュールされていないためです。 エージェントを公開したa7のssh-bridgeも無効になっています。

こんにちは@ingwinlu 、
前回の会議で説明したように、アクセスポイントが必要になります。
メールごとに情報を送っていただけませんAUTHORS.mdにあります。
ところで。 どこにもあなたの電子メールを見つけることができませんでした、多分あなたはこのファイルにあなた自身を追加するべきです。

v2ビルドサーバーは、ベンチマークを実行しているため、31.0709：00までオフラインになります。 ビルド時間が長くなることが予想されます。

ご不便おかけしてすみません。

//編集：ダウンタイムを2時間延長

拡張機能も渡されたようです。 昼食後（13:00頃）に高速ビルドを取り戻すとよいでしょう。 ：笑顔：

mm-debian-unstableがアップグレードされ、オンラインに戻りました。 再アクティブ化してサーバーに固定できるジョブはありますか？

i7のディスクがいっぱいのようです。 私の仕事はNo space left on device （仕事と仕事）で失敗します

ちなみに、私は新しいビルドインターフェイス（dockerization＆jenkinsfile）が本当に好きです。 ビルドエラーの再現に非常に役立ちます。

報告ありがとうございます！

残念ながら、サイズ変更には再起動が必要であり（rootfsを拡張する前に、rootfsを小さくする必要があります）、20Gしかありません。 Jenkinsビルドフォルダーを削除しましたが、それらは小さかったため、99％のままです。

したがって、_dockerのクリーンアップはより効果的です。
@ingwinluは、_docker / overlay2の両方が巨大なようです。 なぜこれらすべてのものがそこに集められたのか考えはありますか？

クリーンアップされたDockerアーティファクトをdocker system prune -fa強制します。 この
Dockerイメージで使用される約190GBのスペースをクリーンアップしました。

午前7時54時月、2018年8月13日には、markus2330 [email protected]は書きました：

報告ありがとうございます！

残念ながら、サイズ変更には再起動が必要です（rootfsを作成する必要があります
もう一方を拡張する前に小さくします）、20Gしか持ちません。 私
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に入れることはできますか？

デイリーは似たようなことをしますが、攻撃的ではありません。 別のものを取る必要があります
私がウィーンに戻ったときに見てください。

markus2330 [email protected] schrieb午前ミズーリ州、13 2018年8月、9：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は、来週の短期間のベンチマークのためにオフラインになる可能性があります。 アントンがベンチマークを開始すると、オフラインメッセージ「ベンチマーク」が表示されます。 コンピュータが長時間（たとえば1日以上）オフラインのままである場合は、お問い合わせください。 （その後、再びオンラインに切り替えるのを忘れていた可能性があります。）

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）で言及されています。

Dockerレジストリへのパブリックアクセスを実装しました。 アクセス方法に関するドキュメントについては、こちらをご覧ください。

何かが期待どおりに機能しない場合はお知らせください。

//編集ログインに成功してもプッシュが機能しないようです。
// EDIT2パブリックアクセスが再び無効になります。 https://github.com/moby/moby/issues/18569。 システムを構築するための復元された機能
// EDIT3：パブリックリポジトリがhub-public.libelektra.orgで再びアップ

アントンは、次の火曜日または水曜日にハイパースレッディングが無効になっているコンピューターのメインボードを交換したいと考えています（選択できます）。 誰かがこれらの2日間のいずれかにビルドサーバーを必要としますか？

Dockerレジストリを再起動し、手動でクリーンアップを実行しました。 うまくいけば、それはウェブサイトの画像に関するビルドの問題を解決しました。

@ingwinluメンテナンス作業ありがとうございます！

残念ながら、WebUIステージは非常に確実に失敗します（例： 321または320） （以前にも失敗しましたが、WebUIをプルするときにも失敗しましたか？）。

マスターの仕事をキャンセルするのは悪い考えだと私はますます確信しています。 ビルドがキャンセルされるか、ネットワークの問題が原因で失敗するため、マスターでのビルドはほとんど成功していません。 コミット履歴では、どちらの方法でも単に失敗として表示されるため、何が起こったのかを判断するのは困難です。

回避策として、c3b59ecef95287ffc33b094b37e03d0ec6b5710fの信頼できないステージを無効にしましたが、すぐに再び有効にできることを願っています。

a7-debian-stretchはベンチマークのためにまだオフラインにする必要がありますか？ （2019年2月21日10:47:56 AM以降オフラインになりました）

報告ありがとうございます！ アントンが再アクティブ化するのを忘れたようです。 ノードを再度アクティブにし、古いノードも削除しました（まだ実行中のmmを除く）。

午前中にサーバーのダウンタイムが発生しました。 すべてが再び実行されますが、ハードウェアを交換するという申し出がありました。 したがって、今日はさらに約1時間のダウンタイムが発生する可能性があります。

サーバーは再び稼働しています。 残念ながら、同じハードウェアを入手しました。 誰かがインストール/セットアップの時間がある場合は、ハードウェアをアップグレードできます。

Jenkinsのビルドは非常に遅いようです（完全なビルドの場合は数時間）。 私の知る限り、テストを実行しているのはa7-debian-stretchとi7-debianだけで、他のすべてのノードはアイドル状態です。 これは予想される動作ですか？

この問題を報告していただきありがとうございます。

いいえ、これは予期された動作ではありません。 v2がダウンしているようです。 できるだけ早く再起動します。

v2が再び起動するはずです

v2はダウンしており、月曜日までこのままになるのではないかと心配しています。 それまではビルドが非常に遅くなります。

v2は再び新しいメインボードで稼働しています

＃2852を回避するために、3つのビルドエージェントすべて（i7、v2、a7、この順序で）をバスターにアップグレードします

ダウンタイムを可能な限り最小限に抑えるように努めます。 ビルドジョブが失敗する可能性があります。再起動してください（エージェントが再び起動した後）。

i7-debian-buster、以前のi7-debian-stretchが再びオンラインになりました

v2は次です

v2-debian-busterとa7-debianbusterも再びオンラインになりました

マスターで以前に成功したビルドジョブを再開して、すべてが再び機能するかどうかを確認しました。
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（a7を介してブリッジを介して接続されています）もダウンしています。

そのため、現在、ビルドを実行することはできません。 管理者に連絡しました。

すべてのサーバーが再び稼働しています。 新しいコミットをプッシュするか、PRへのコメントとして「jenkinsbuild libelektra please」と書き込んで、ビルドを再開してください。

テクニカルノート：「ウォッチドッグバグソフトロックアップ」のためにa7がダウンしました。 「nomodesetnmi_watchdog = 0」を追加してみました。 彼らが以前ほど不安定にならないことを願っています。

a7（および、v2とi7はa7を介してブリッジを介して接続されているため）がダウンしています。 管理者に連絡しました。 キューが長くなるだけなので、今すぐビルドを開始しないようにしてください。

a7はオンラインに戻りました（すでに昨日でした）、v2は影響を受けませんでした

ビルドサーバーのステータスページによると、サーバーは次のようになります。

• a7-debian-buster 、
• i7-debian-buster 、および
• v2-debian-buster

ダウンしています。 Jenkinsデータディレクトリもかなりいっぱいのようです。 そして、私たちがそれに取り組んでいる間：Jenkinsとそのプラグインをアップグレードできれば素晴らしいと思います。 私はこれらの問題を解決することに興味があります。 ただし、2つの問題があります。

1. 私はサーバーの管理の経験があまりありません（または実際にはまったくありません）。
2. マシンは非常に不安定なように見えるので、おそらくマシンに物理的にアクセスする必要があります。

a7はi7とv2へのブリッジであるため、a7がダウンしていると、i7とv2についてはわかりません。

アクセスは問題ありません、私はあなたにそれを与えることができます。 ただし、Jenkinsのアップグレードは、通常Jenkinsの再構成（リリースノートによると、しばらくの間アップグレードしなかったため）とJenkinsfileの修正（プラグインからのAPIの変更による）が必要になるため、大規模な操作であることに注意してください。 ）。 アクセスしたい場合は私にメールを送ってください。

a7（および他のすべて）が再び稼働しています。

a7が再びダウンしたので、管理者に連絡しました。

テクニカルノート：「ウォッチドッグバグソフトロックアップ」のためにa7がダウンしました。

クイック検索は、これがBIOSの問題である可能性があることを示しています。 BIOSアップデートが利用可能かどうかを誰かが確認しましたか？

a7はi7とv2へのブリッジであるため、a7がダウンしていると、i7とv2についてはわかりません。

それは悪いデザインのようです。 それを回避する方法はありませんか？

クイック検索は、これがBIOSの問題である可能性があることを示しています。 BIOSアップデートが利用可能かどうかを誰かが確認しましたか？

新しいBIOSをインストールし、CPUを交換し、カーネルをアップグレードしました（上記のメッセージを参照）。 それ以来、システムは安定していた。 Debianバスターにアップグレードした後、再び不安定になりました。

それでも、新しいBIOSが利用可能かどうかを管理者に尋ねました。

それは悪いデザインのようです。 それを回避する方法はありませんか？

十分なIPv4アドレスがないため、i7とv2はプライベートネットワークにあります。 管理者に、IPv6のセットアップが可能かどうか尋ねました。

管理者に、IPv6のセットアップが可能かどうか尋ねました。

IPv6は実際には必要ありません。ブリッジとして、より安定した別のサーバーを使用するだけで十分です。

ほとんどの場合、v2はa7と同じくらい不安定です（クラッシュは1回だけでしたが、a7が停止するとすぐに、v2の負荷がかかるため、これはあまり意味がありません）。 i7をブリッジとして使用できます。 しかし、v2とa7がダウンした場合、i7もあまり役に立たず、ビルドジョブを完了するのに何時間もかかります。 さらに、i7にはdockerレジストリ用の十分なスペースがありません。

したがって、この変更はほとんど利益をもたらさずに多大な労力を要します。

a7とv2の実際の問題を修正することは、はるかに有望です。

さらに、i7にはdockerレジストリ用の十分なスペースがありません。

その場合、唯一の解決策はa7を修正することです。

残念ながら、a7は再びダウンしています：cry：

古いカーネルで起動しようとしましたが、これは役に立ちませんでした。

BIOSには他にもいくつかのバージョンがありますが、リリースノートによると、この問題が修正される見込みはほとんどなく、悪化した場合に再度ダウングレードする方法はありません...

a7のBIOSは現在アップグレードされています。 さらに、バックポートから新しいカーネルを使用しようとします。

a7がすぐにまた稼働することを願っています。

新しいBIOSは役に立ちませんでしたが、a7は数分以内にクラッシュしました。

a7が再びダウンしたので、管理者に連絡しました。 バックポートからの新しいカーネルは、次の再起動で試行されます。

a7は5.2カーネルで再び稼働しています

また墜落したと思います...

それでも同じエラーメッセージが表示されますか、それとも少なくともいくつかの変更がありますか？

はい、a7が再びダウンしました、私は管理者に報告しました。 再起動時のメッセージについて教えてくれます。

誰かが別のアイデアを持っていますか？ （BIOSとカーネルはすでにアップグレードしています。）

一部の情報源は、nouveauグラフィックドライバの問題を示唆しており、 nouveau.modeset=0を試す必要があると示唆しています（どういうわけか、これはnomodesetとは異なります）。 また、BIOSで「C-states」を無効にすることも提案されました。

はい、a7が再びダウンしました、私は管理者に報告しました。 再起動時のメッセージについて教えてくれます。

誰かが別のアイデアを持っていますか？ （BIOSとカーネルはすでにアップグレードしています。）

おそらく、a7をjenkinsスレーブとして無効にして、「実際の」負荷がマシンにある場合にのみ発生するかどうかを判断します。

@ingwinluありがとう、いい考え。 私は今、a7を1つのビルドジョブに減らしました（それは2でした）。 週末（管理者がオフィスを離れた後）は、エージェントを完全に無効にします。

@kodebach ：ありがとうございます。情報を管理者に転送します。

a7が再び稼働する時期についてのタイムラインはありますか？

a7が再び起動し、ハイパースレッディングがオフになり、同時ビルドジョブが1つだけになります。

alpineとubuntu-xenialビルドをCirrusに移動することで、a7の負荷の一部を取り除くこともできます。 どちらも単純な「ビルドとテスト」の実行です。 彼らは報道の報道のような特別なことは何もしていません。

Cirrusでは、ユーザーごとに8つのLinuxビルドを同時に実行できlinkcheckerビルドはCirrus上の唯一のLinuxビルドです。

実際、TravisビルドはUbuntu Xenialで実行されるため、 ubuntu-xenialは少し冗長です。

ヒントをありがとうございますが、LinuxビルドをJenkinsからオフロードする予定はありません。 それどころか、 @ Mistreatmentは、Jenkinsインフラストラクチャをさらに最新かつ有用なものにするために（たとえば、より多くのパッケージを構築することによって）改善することに取り組んでいます。 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のハーバート

「a7istleidernichterreichbar」と言えば十分です。

そして、ハーバートが複数の電子メールを受け取らないように、ここでも報告してください。

確かに、Jenkinsマスターサーバーにそのような電子メールを自動的に送信させ、おそらくこのGitHubの問題に投稿させる方法があります。 このような単純なタスク用のJenkinsプラグインがなかったとしたら、それは非常に奇妙なことです...

はい、 https：//wiki.jenkins.io/display/JENKINS/Mail+Watcher+Pluginがあり

何かを自動化した場合、PCに到達できない場合は、PCを直接再起動します（おそらく、何らかのウォッチドッグが組み込まれているのでしょうか？）

a7が再起動され、「グローバルC状態制御」が無効になりました。

ただし、ビルドエージェントとしてオンラインではありません。

負荷なしでもクラッシュするかどうかを見てみましょう。 v2とi7は再び動作します。

管理者（ハーバート）は明日利用できないので、今のところビルドエージェントとしてa7をオフのままにしておきます。

私の計画（以前に抗議やa7のクラッシュがなかった場合）は、明日ビルドエージェントとしてa7をオンにすることです。 a7がクラッシュした場合、ハーバートは金曜日にa7を再起動できます。 これは大丈夫ですか？

キューが長すぎない場合は、a7のビルドエージェントをもう少し無効にしておく必要があると思います。 最後のクラッシュは3日後に発生しました。 明日有効にした場合、それ以前にクラッシュしない限り、ビルドエージェントがクラッシュを引き起こしたかどうかはわかりません。

では、キューのサイズがどのようになるか見てみましょう。

「グローバルCステートコントロール」が最終的に問題を解決することを願っています。それをテストするには高負荷が必要だと思います。

キューは非常に長く、Webサイトの展開にa7が必要なため、マスタービルドはすべてハングしていました。

そこで、a7エージェントを再開しました。

メインビルドサーバーのディスク容量が不足しているため、最近のJenkinsビルドジョブの一部がキャンセルされました。 古いビルドジョブのログを削除して、スペースを解放しました。 新しいビルドジョブのいくつかのログファイルも削除した可能性があることに注意してください。 場合によっては、最新のコミット用のJenkinsビルドが失敗し、404エラーに隣接するメッセージのみが表示されることがあります。 その場合は、どちらかをお願いします

• PRの下のコメントでjenkins build libelektra pleaseして、Jenkinsビルドを再起動するか、
• 最後のコミットを変更せずに書き直し（たとえば、 git commit --amend ）、強制的にプッシュします

。 ご不便おかけしてすみません。

メンテナンスありがとうございます！

ノードv2-debian-buster正しく機能していないように見えるため、

インフラをお探しいただきありがとうございます！

v2のディスク容量が不足していました。 docker system pruneを実行しました。再生スペースの合計：58.37GB

次に、v2を再起動し、エージェントを再度接続しました。

du -h | sort -hを実行して、削除する他のファイルを見つけました。

新しいDockerバージョンでv2を再開しました。 壊れたビルドをすぐに報告してください。

dockerを再インストールし、すべての構成を削除して、/ 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

壊れたビルドをすぐに報告してください。

v2-debian-busterへの接続の問題が原因で、 masterビルドが再び失敗したようです（問題＃2995も参照）。

管理者にa7 / v2 / i7間の切り替えを確認するように依頼しました。 今のところv2とi7を無効にしました。

libelektra / masterとlibelektra-dailyを再起動しました。

3台すべてのPCのポートを変更しました。

次に、v2 / i7でjenkinshomedirを削除し、v2 / i7エージェントを再起動しました。

v2-debian-buster利用可能なスペースがです：

ApplyLayerの終了ステータス1stdout：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]

来週の初めにすぐに移行できることを願っています（ @Mistreatment ？）

サーバーは現在、RAIDの再同期を行っているため、非常に遅いと予想されます。

Jenkinsビルドは実行されなくなりました。＃3035を参照してください。

ジェンキンスは今再び始めました。 Jenkinsビルドジョブを繰り返してください。

v2-debian-busterがオフラインのようです：

a7.complang.tuwien.ac.at:22221へのSSH接続を開いています。
接続が拒否されました（接続が拒否されました）

。

ありがとう、私は私たちの管理者に連絡しました、しかし私は彼がすでに不在になるのではないかと心配しています。

ハーバートは昨日すでにv2を再起動しました。 彼は「同時マルチスレッディング」を無効にしました。

サーバー（v2、i7、a7）が再びクラッシュした場合は、「herbertatcomplang.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

。 ビルドをすでに3回再起動しましたが、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

ここで、masterのディレクトリ全体を削除し、ビルドを再開しました。 ＃3054も参照してください

数日間ご利用いただけないため、到達不能なa7 / i7 / v2に関する問題については、「herbertatcomplang.tuwien.ac.at」までお問い合わせください。 @Mistreatmentは、サーバーの再起動に関係のないすべての責任を負います。 （うまくいけば、新しいビルドエージェントをすぐに入手できます。）

また、複数の電子メールを避け、誰もが何が起こっているのかをよく理解できるように、常にここに報告してください。

ビルドサーバーは現在誤動作していますか？
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

ビルドサーバーは現在誤動作していますか？

メインのJenkinsビルドサーバーがi7に接続できないようです。 ノードを一時的にオフラインとしてマークしました。

ビルドは任意の場合に失敗します：
ここでは理由もなく中断されました
ここで、私のPRとは関係のないテストケースが失敗します（コードに触れることなく設計上の決定を追加しました）

ここでは理由もなく中断されました

2つのPRに対して同じ割り込みコード143を取得しましたが、まだ説明できません。 ビルドを再開しましたが、うまくいくことを願っています。

ここで私のPRとは関係のないテストケースが失敗します

これは、＃3103の@sanssecoursのおかげで修正されるはずです。 マスターにリベースしてください。

新しいJenkinsノードhetzner-jenkins1が正しく機能していないようです。 ノードを一時的にオフラインとしてマークしました。

i7でdockerをアップグレードし、マシンを再起動しました。 これで問題が解決することを願っています。 エージェントは再びオンラインになります。 ここで問題を報告してください（および/またはエージェントを非アクティブ化してください）。

現在、＃3065のジョブがi7で実行されています。

@Mistreatment 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をしました。

しばらくの間、リンクチェックを簡単にオフにする可能性はありますか？

個々のリンクをtests / 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プロセスを強制的に強制終了します。

また、すべてのエージェントでdockerをアップグレードしました（i7ではすでにアップグレードされています）。

Jenkinsは、＃2984で提案されているように、ハートビート間隔で再び稼働しています。 すべてのノードが接続されています。

必要に応じてすべてのジョブを再開し、ここで問題があれば報告してください。

v2がダウンしているので、管理者に再起動するように依頼しました。

v2が稼働しているようで、ビルドバックログのサイズが適切であるため、v2を再度有効にしました。

ビルドに問題がありますか（ hetzner-jenkins1 ）？
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

ビルドに問題がありますか（ hetzner-jenkins1 ）？

はい。 ノードを無効にしました。

ディスククォータを超えただけで、メモリで過剰に殺したくありませんでした。 私は今それをきれいにしました。 その再び。

ノードが更新されました。

hetzner-jenkins1を4つの並列ビルドに増やしました。 これは、他に何も実行されていない限り、一時的な手段にすぎません。

テストスイートがタイムアウトしているため、hetzner-jenkins1のエグゼキュータの数を一時的に4から2に減らしました。 これは、テストの実行中にコンパイルするジョブが多すぎる場合に発生すると思います。 他のジョブにあまり干渉しないように、使用可能なリソースを単一のコンテナーに制限する必要がある場合があります。

これが間違ったアプローチだと思われる場合は、遠慮なく修正してください。

編集：テストはまだタイムアウトしており、絶えず再構築するとさらに多くのリソースが無駄になるため、1に減少しました。

@mpranj修正していただきありがとうございます！

@mistreatmentは、おそらく単一のCPUまたは同様のもののみを割り当てましたか？ より多くの割り当てを行い、エグゼキュータの数を増やすことはできますか？ ハードウェアはv2よりも強力である必要があります。

すべてのビルドが失敗する原因となるディスク領域が残っていないため、 i7-debian-busterを無効にしました。 誰かがアクセスできる場合は、何かをクリーンアップして再度有効にしてください。

@mpranj無効にして

申し訳ありませんが、現在sshがブロックされています（一部のアプリケーションファイアウォール、他のポートのsshも機能しません）。 そのため、現在、アクセスを許可したり、クリーンアップを実行したりすることはできません。

i7はエージェントの中で最も弱いので、とにかく大したことではないかもしれません。

@虐待あなたはたぶん単一のCPUまたは同様のものだけを割り当てましたか？ より多くの割り当てを行い、エグゼキュータの数を増やすことはできますか？ ハードウェアはv2よりも強力である必要があります。

v2がどれほど強力かわかりません。
現在、 jenkins1は8つのメモリと16のスワップを備えた4つのCPUを使用しています。 私はそれを簡単に増やすことができます、私はあなたが私にそれを増やして欲しいポイントがわからないだけです。

将来のハードウェア決定に関する注記：phoronixはCPU記事でコンパイルテストを行っているようです（例： Ryzen 7 3700X、Ryzen 9 3900Xテスト、記事の下端に向かって）。

hetznerが最近AMDRyzen 73700XをAMDベースのサーバーに追加したようです。

v2がどれほど強力かわかりません。

@ingwinluは彼の論文でこれについて書いています（abgaben repo lukas_winklerにあります）

現在、jenkins1は8つのメモリと16のスワップを備えた4つのCPUを使用しています。 私はそれを簡単に増やすことができます、私はあなたが私にそれを増やして欲しいポイントがわからないだけです。

サーバー上で他に何も実行されていない限り、すべてのリソースを割り当てることができます。 後で（ジェンキンスを移動するときに）まだ降りることができます。

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％/

次に、エージェントを再起動しました。

@Mistreatmentは、これがそれほど速く再発しないように＃3160を修正してください。 hetzner-jenkins1も修正してください。 このマシンには多くのリソースがあり、毎日リソース制限に達する必要はありません。

ディスクのサイズを小さくする良い方法があるかどうかはわかりません。 そのため、Imはノードにすべてを一度に与えないのです。hetznerが再び起動します。

v2が再びスペース不足になったので、クリーンアップしました：/ dev / sda3 417G 315G 102G 76％/

@虐待https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/logが起動しない

ビルドシステムは現在完全にスタックしていると思います。PRはビルドされていません。

報告していただきありがとうございます。ディスクがいっぱいになったら、Jenkinsを再起動し、いくつかのファイルをクリーンアップします。

@虐待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」にコピーできませんでした。

修正済み（スペースも不足していました）

@Mistreatmentは、jenkinsを修正してください-これにより、クリーンアップタスクが常に手動で実行する必要があるため、毎日です！

@Mistreatment 「jenkinsbuildlibelektraplease」はまだ壊れていますが、これはWebhookの変更に関連していますか？

今日、新しいJenkinsに変更してみてください。それができない場合は、古いインスタンスを再度機能させてください。

リポジトリスキャンをトリガーしましたが、「jenkinsビルドlibelektraお願いします」が再び機能するようです。

v2-debian-busterディスクがいっぱいになっているようです

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2976/2/pipeline

不幸にも。 v2を解決するまでオフラインとしてマークしました。

報告ありがとうございます！

@mpranjアクセス権を付与しましたが、クリーンアップしていただけますか？

ありがとうございました！ Dockerの古い画像が横になっているために無駄になっているリソースが豊富にあるように思われます。 さらに、btrfs + dockerにはバグがあるようです。 Dockerは、コンテナーごとにbtrfsサブボリュームを作成し、その後は適切にクリーンアップしません。 docker system prune -fコマンドもスペースを解放しません。

リソースを解放してbtrfsのバランスを取るために、メンテナンスのためにv2とa7削除しました。

dockerログインに失敗しました

カントプルドッカーイメージをビルドします。 Dockerハブで何かが起こっていますか？

はい、申し訳ありませんが、 a7を使用して、Dockerハブも削除しました。 再びアップしたら、ここにメッセージを投稿します。

Dockerハブを含むa7が再び稼働しています。 ハブにログインしてイメージをプルできないため、 v2オフラインのままにしましたか？！？ 何が問題なのかわかりません。クレデンシャルなどを変更しなかったので、他のノードはログインできます。 何か案は？

Btrfsはまだバックグラウンドでバランスを取っているため、 a7はさらに1時間ほど遅くなる可能性があります。

@mpranjこれを修正して

残念ながら、私は資格情報を知りません。 @ ingwinluが私たちを助けてくれることを願っています。

リバランスに使用したコマンドは次のとおりです。

btrfsで多分バグを修正します：

btrfs balance start -dusage=0 -musage=0 /mountpoint

本当にfsのバランスを取り直してください。これには長い時間がかかります。 使用パラメータは調整可能/調整する必要があります。これが今日機能したものです。

btrfs balance start -dusage=80 /

クレデンシャルは簡単に変更できますが、新しいクレデンシャルを使用してDockerハブに再度接続するすべてのjenkinsエージェントにログインする必要があります。

より大きな問題は、一部のDockerコンテナーがまだ実行中であり、Dockerシステムのプルーニングがあまり機能しないことでした。 したがって、私はエージェントをダウンさせ、ダウンしている間にすべてを解放しました。 ちょうど周りにたくさんのコンテナがありました。

はい、残念ながらコンテナはすぐに再作成されます。 @Mistreatmentがlibelektra-dailyジョブをすぐに修正できることを願ってdocker system prune実行します）。

また、かなり複雑なデジタルフォレンジックを実行し、ハブの資格情報を盗みました。 ：笑い：

v2が再び稼働しています。

どうもありがとう！ ：100：クレデンシャルを送ってください。

送信済。 ところで、 a7はおそらくディスク速度が遅いという理由だけで遅いと思いますが、Dockerハブ用の十分なスペースがあるのは良いことです。 多くの場合、CPUはそこで何もしていないようです。

別の考え：現在のような状況を回避するために、cronjobごとに重要なクリーンアップジョブを追加で実行できる可能性があります。

クレデンシャルを送ってください。

@mpranj私はこの「私たち」のグループにいたと思います。 私はいくつかのCCまたはそのようなものにいませんでしたか？

@虐待申し訳ありませんが、私はそれをマルクスに送りました、そしてあなたの電子メールを持っていませんでした。 a7 CREDENTIALS.txtでは、homedirに

新しいjenkins-serverをテストするには、hetzner-jenkins1ノードが必要です。 明日の朝まで古いサーバーでオフにします。

テスト用に2番目のhetzner-jenkins2を簡単に作成できます。 今夜だけなら大丈夫です。

別の考え：現在のような状況を回避するために、cronjobごとに重要なクリーンアップジョブを追加で実行できる可能性があります。

libelektra-毎日このクリーンアップジョブを実行しますが、現在は失敗します：＃3160。 この仕事を改善するためのアイデアがあれば、教えてください。

私はこの「私たち」のグループにいたと思います。 私はいくつかのCCまたはそのようなものにいませんでしたか？

はい、申し訳ありませんが、「私たち」があなたを指していることをmpranjに伝えるのを忘れました。

しばらくの間hetzner-jenkins1を維持しても大丈夫だといいのですが、今夜はサーバーを完全に稼働させることができると思います。

v2に到達でき

hetzner-jenkins1をしばらく保持しても問題ないことを願っています。今夜はサーバーを完全に実行できるようになり、すべてのビルドが正常になりました。

これは素晴らしいことです！

v2にアクセスできません。管理者に連絡しました。

ありがとうございますが、彼は月曜日までに返答しないのではないかと思います。

v2は新しいカーネルを取得します（クラッシュしたばかりです）。

i7も再起動されます。

3つのサーバー（v2、a7、i7）すべてに「Linuxv2 5.2.0-0.bpo.2-amd64＃1 SMP Debian 5.2.9-2〜bpo10 + 1（2019-08-25）x86_64 GNU / Linux 「」

それらは稼働していてオンラインです。必要に応じてジョブを再開してください。

注：
新しいサーバーでリポジトリを再度スキャンしました。 これにより、古いものでエラーが発生する可能性があります。

マスター[1]も新しいサーバー上に構築されたようです。 うまくいきませんでした。 ステータスをクリックすると、ログインページが表示されます[2]。 ログインしなくてもすべてを表示できるようにJenkinsを再構成してください。

うまくいけば、すぐに新しいJenkinsに切り替えることができます。 2つの異なる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をリモートで再起動できますか、それともいくつかの落とし穴がありますか？

通常は機能しますが、緊急でない場合は、管理者がそこに来るまで待つことをお勧めします。 火曜日に再起動できますか？

ありがとうございました！ 緊急なことは何もありません。一般的な質問です。 Debian10.2がリリースされたばかりだったので思いついた。 アップグレードを少し待ちます。

それでもアップグレードは実行できます（再起動せずにのみ）。 次に、クラッシュが発生した場合、管理者がリセットボタンを押すと10.2カーネルがすでに存在します：wink：

@mpranj古いスナップショットを

https://docs.docker.com/storage/storagedriver/btrfs-driver/は、cronジョブでbtrnfsのバランスを取り直すことも推奨しています。

古いスナップショットを削除するcronジョブを追加できますか？ または、Dockerを停止せずにこれを行うことはできませんか？

すべてのDockerコンテナを停止せずにcronジョブを追加できます。 これですべてがクリーンアップされるわけではありませんが、試すことはできます。 私が言ったように、時々コンテナは永久に/マシンがクラッシュするまで実行し続けます。 ただし、完全なクリーンアップでは、ビルドエージェントを一時的に無効にする必要があります。その後、すべてのコンテナーを強制的に停止できます。

リバランスをcronジョブとして追加することもできます。

ありがとう、やってみよう。

マスターのメモリが不足しています。 Dockerイメージのプル時にa7とi7で次のエラーが発生するため、古いJenkinsでスキャンリポジトリを実行したかったのです。

dockerログインに失敗しました

新しいサーバーでv2とhetzner-jenkins1を実行しています。

マスターのメモリが不足しています。

報告していただきありがとうございます。 古いカバレッジデータをいくつか削除し、マスターノードを再度有効にしました。 オープンプルリクエストをお持ちの方へ：Jenkinsビルドをjenkins build libelektra please再起動してください。 ご不便おかけしてすみません。

＃3234で@ raphi011が提案しました：

imoこれは本当に緊急です。テストの不安定さと遅さにより、検証するためにこれだけ長く待たなければならない場合、変更を行うことは不可能ではないにしても困難になります。

私はそれが本当に緊急であることに同意しますが、 @ Mistreatmentはすでに彼ができることをしています。

したがって、ビルドサーバーをより慎重に使用し、PRがまもなくマージされると本当に考えている場合にのみビルドできる可能性があります。 不要なビルドはキャンセルする必要があります。

または、変更のプッシュ時にPRの自動ビルドを（一時的に）停止するのはどうですか（ビルドはjenkins build libelektra pleaseのみ開始されます）。 @Mistreatment Jenkinsを再構成してそうする方法を知っていますか（オプションが見つかりませんでした）？

また、現時点ではjenkins build libelektra pleaseが機能しないと感じていますが、少なくともこのビルドでは機能しませんでした： https ：

cronjobのクリーンアップが実装され、バックポートカーネルがa7および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

手動のクリーンアップ、カーネル、およびDockerのアップグレードのためにi7を無効にしました。 私が作業しているときに、誰かがi7を有効にしました。 すべてが再び稼働しています。

@Piankeroビルドを再開しました。

また、現時点ではjenkins build libelektra pleaseが機能しないと感じています。少なくとも、このビルドでは機能しませんでした。＃3073パイプラインを開始するために空のコミットをプッシュする必要がありました。

今動作します

@Mistreatment Jenkinsを再構成してそうする方法を知っていますか（オプションが見つかりませんでした）？

Jenkins構成に以下を追加しました。

自動SCMトリガーを抑制します

全員への注意：「jenkinsbuild libelektra please」の使用は必須になりました。ビルドジョブは、単にプッシュするだけでは開始されません。 この設定を元に戻すときに、ここで通知します。

@虐待ありがとうございます！ これで十分かどうか見てみましょう。 マスターへのプッシュがまだマスタービルドをトリガーすることを願っていますか？

それでも、ヘッツナーノードがあると非常に便利です。 ノードが2つのビルドサーバーによって同時に使用されている場合、問題はありますか？ または、それが問題である場合：CTのクローンを作成するのは非常に簡単ではありませんか？

@虐待ありがとうございます！ これで十分かどうか見てみましょう。 マスターへのプッシュがまだマスタービルドをトリガーすることを願っていますか？

マスターブランチは、次のルールの例外になりました。

自動SCMトリガーを抑制します

はどうかと言うと

それでも、ヘッツナーノードがあると非常に便利です。 ノードが2つのビルドサーバーによって同時に使用されている場合、問題はありますか？ または、それが問題である場合：CTのクローンを作成するのは非常に簡単ではありませんか？

新しいCT（hetzner-jenkinsNode3）を追加しました。

リポジトリのクローンを作成できませんでした： https ：

多分これは新しいノードと関係がありますか？ （当てずっぽう）

多分これは新しいノードと関係がありますか？ （当てずっぽう）

このエラーはa7にあります

このエラーはa7にあります

すっごく..再試行しますか？

すっごく..再試行しますか？

ええ、私はそれが再び起こるとは思わない。

私はあなたのためにそれを再実行します。

@Mistreatment自動ビルドを再開できると思います。 しかし、最初に＃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にアクセスできます。

長期的には、Dockerイメージにこの種の依存関係を設定して、ビルドごとに繰り返しダウンロードしないようにすることをお勧めします。 これにより、上記のように一時的に利用できないパッケージによるビルドの失敗も防ぐことができます。

それでは.. jenkins build libelektra please 3番目

はい、まさにこの理由から、Dockerイメージに直接すべての依存関係があります。 ＃3251を作成しました

再起動のためにv2とa7をオフラインにしました。

@ markus2330機会があれば、 a7ハイパースレッディングを有効にします。

v2は再び稼働し、a7にはまだビルドジョブがあります。

ノードを取得して、新しいサーバーに追加しました。 私はそれを一晩走らせるつもりです。 明日、新しい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

@Mistreatmentは、PRが自動的に作成されることを再度アクティブ化できますか？ 多くのエージェントが原因で、サーバーは現在ほとんどの時間スリープしています。

@Mistreatmentは、PRが自動的に作成されることを再度アクティブ化できますか？ 多くのエージェントが原因で、サーバーは現在ほとんどの時間スリープしています。

終わり。

新しいサーバー用にhetzner-jenkins1とv2もう一度借ります。

あなたはそれを返す必要はありません、私たちは今日切り替えを行うことができることを願っています。

ヒント：この種の切り替えを行うときは、DNSエントリのTTLを異常に低い値に下げることをお勧めします（たとえば、build.libelektra.orgの現在の21599ではなく60）。 変更が反映された後、数時間ではなく1分以内にDNSエントリを切り替えることができます。 手遅れの場合は、googleとopendnsのDNSキャッシュをクリアするのに役立ちますが、キャッシュされたエントリがグローバルに期限切れになるまで、必然的に古いリソースが表示される場合があります。

編集：変更後、DNSにかかる負荷を軽減するために、TTLを適切な値に戻す必要があります。

今では手遅れかもしれませんが、 $TTL 3600を切り替えました（すべてが機能するまでいくつかの変更が必要な場合）。

www-newとbuild-newは、新しいサーバーを指すように既に存在します。

doc.libelektra.orgを切り替えました。 @Mistreatmentは公開を修正します。 www-new.libelektra.orgを調べます

https://build-new.libelektra.org/およびhttps://www-new.libelektra.org/homeが機能するようになりました。

ここですべてのDNSエントリを変更します。

すべてのDNSエントリが変更されます。

残念ながら、certbotは古いサーバーと通信しているように見えるため失敗しますが、これはダウンロードとコミュニティ（あまり使用されていないURL）にのみ影響するようです。

したがって、週末の最中/後に、更新されたDNS名がすべての人に表示されることを願っています。

@Mistreatmentは、すべてのアーティファクトの公開を更新してください：Webサイトについても。 PRを作成して、すべてが正しく機能していることを確認してください。

古いビルドサーバーがシャットダウンされました。

新しいサーバーを再起動する必要があります（新しいカーネルとネットワークブリッジが追加されました）。

Linux pve5.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）

@Mistreatmentマスターも自動的にビルドされなくなったようです。手動でトリガーするようになりました。

＃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 ：

報告ありがとうございます！

@Mistreatmentすでに何度も議論されているように、 いただけませんか？ （Jenkinsに変更を加える前にスナップショットを作成してください。）

hetzner-jenkins1 ：ディスククォータを超えました

@Mistreatmentすでに何度も議論されているように、 いただけませんか？ （Jenkinsに変更を加える前にスナップショットを作成してください。）

今日やるよ

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のスペースをクリーンアップし、再度有効にしました。

どうもありがとうございます！ そこでcronジョブを作成することもできますか？ （コンテナーではなくVM上）。

そこでcronジョブを作成しますか？

終わり。

@Mistreatmentすでに何度も議論されているように、 いただけませんか？ （Jenkinsに変更を加える前にスナップショットを作成してください。）

naginatorプラグインが必要な場合は、パイプラインからフリースタイルジョブに移行する必要があります。 私は代替案を探すつもりです。

現在、VM jenkinsNode3VMビルドは失敗します。 Dockerプルすることはできません：

unexpected EOF
script returned exit code 1

誰かが問題を解決できるまで、私は今のところそれを無効にしました。

[cronjob]完了しました。

ありがとうございました！

naginatorプラグインが必要な場合は、パイプラインからフリースタイルジョブに移行する必要があります。 私は代替案を探すつもりです。

はい、良い考えですね。 たぶん、それをJenkinsfileに単純にコーディングするのが最善でしょう。 したがって、問題のあるビルドジョブ/ステージが失敗した場合は、再試行されます。 これは最も頻繁な問題の1つであるため、これらのDockerプルは少なくとも2回試行されます。

VMでのビルドjenkinsNode3VMは現在失敗しています。 Dockerプルすることはできません：

@虐待これを修正してください。

VMでのビルドjenkinsNode3VMは現在失敗しています。 彼らは港湾労働者を引っ張ることができません

プルできないDockerイメージを修正しました。

どうもありがとうございます！ 何が間違っていて、どのように修正したかを書くと、常に役に立ちます。

何が悪かったのかわかりません。エージェントで手動でイメージを作成しました。 エージェントが引っ張ることができなかったので。

Dockerfile (scripts/docker/debian/stretch) 、私のVisual Codeは、最後に2つの空の行があると言っていますが、 vimは1つだけだと言っています。 私はそれが上記の間違いで何かをしなければならないのか分からない、多分それは私のVSだけだろう。

Dockerレジストリに問題があるようです（＃3316 docker pullがunexpected EOF失敗します）。

リリース後のほこりは落ち着き、ビルドは行われていないので、すべてを停止してレジストリを完全にクリアすることをお勧めします。 その後、すべてのイメージをきれいに再構築する必要があります。 念のため、開始する前にレジストリデータをバックアップしますが、クリーンスタートで発生していたエラーがなくなることを願っています。

始める前に、それに対して何か反対があるかどうかコメントを待ちます。

私はそれが問題だと思います

（scripts / docker / debian / Stretch）

失敗しているのはそれだけなので、画像。

手動で再度作成しましたが、レジストリのイメージに間違いがあります。

Jenkinsレポート：jenkinsNode3VM（オフライン）

@Mistreatmentは、何らかの監視方法を設定できれば素晴らしいと思います。

a7 （したがって、 v2とi7 ）がダウンしています。 管理者に連絡しました。

markus2330を編集：再びアップ

2020年7月8日にウィーン工科大学で計画停電が発生したため、管理者は前日（火曜日7.7）にすべてのビルドサーバーをシャットダウンする予定です。 その間、ビルドは非常に遅くなりますので、緊急の場合にのみその日にプッシュしてください。

i7を除いて、サーバーは再びオンラインになります。 管理者に通知しました。

昨日の夕方に別の停電（計画外）があったため、すべてのビルドサーバーがダウンしています。 管理者はそれに取り組んでいます。

30分後に編集：i7を含むすべてが再び稼働します：rocket：

@ markus2330 v2とi7は最近インターネットにアクセスでき

変更についてはわかりませんが、これら2つの停電（1つは計画的、もう1つは計画外）の後でコンピューターの電源が再びオンになったということだけです。

しかし、あなたは正しいです、私はまた、これらの2つ（a7ではない）は到達可能ですが、インターネットに接続できなくなっていることもわかります。 私はそれについて私たちの管理者に尋ねました。

この問題が修正されるまで、Jenkinsからそれらを切断する可能性がありますか？

管理者に連絡していただきありがとうございます。 問題が解決するまで、i7とv2の両方を切断しました。 （ビルドはDockerイメージをプルできないため、とにかく機能しません）

約1週間前に誰かがルーターで何かを変更しました。 その人は通知を受けました、そしてうまくいけばすぐにそれを修正するでしょう。

今のところ、それらを切断したままにしておきましょう。

インターネットの問題は解決され、これらのマシンにもセキュリティアップデートをインストールしました。

@mpranjもう一度オンにしてください。

@ markus2330ありがとうございます。

これで、すべてのノードがオンラインに戻りました。

最新のPVEカーネルのビルドサーバーを再起動しました。 Jenkinsはまもなく稼働するはずです。

引っ越した

• []ビルドが失敗した場合のメール送信の信頼性を高める
• [] JenkinsユーザーのいないDockerイメージ
• [] centOS / fedora / archdockerイメージ
• [] 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：15CET頃からメンテナンスのためオフラインになります。

いくつかのバックアップおよびクリーンアップタスクを実行し、 a7パフォーマンスの向上を試みます。

メンテナンスが終了すると、再度通知されます。

JenkinsCIとすべてのビルドサーバーが再び稼働します。 a7パフォーマンスは大幅に向上するはずですが、ストレージ容量は少なくなります。

エラーが発生した場合は報告してください。

Jenkins CIとビルドエージェントは、短いメンテナンス/更新のためにオフラインになります。

編集：更新が行われます。

サーバーがダウンしています。調査します。

サーバーは再び稼働しています。

原因に関する公式声明：「隣接サーバーのPSUに問題があり、サーバーがシャットダウンしました。現在は修正されています。」

a7のssdがいっぱいで、その上にあるすべてのビルドが失敗します。

スペースを空けてみます。 今のところ、 a7ビルドエージェントをjenkinsから切断しても安全ですか？

ご覧いただきありがとうございます！

スペースを空けてみます。 今のところ、a7ビルドエージェントをjenkinsから切断しても安全ですか？

もちろん。 逆に、すべてのビルドが失敗した場合、接続を維持することは安全ではありません。

docker system prune -a実行すると、スペースの約50％が再びクリーンアップされました。 -aフラグを追加するために、既存のcronジョブを適応させる必要があるかもしれません。

ジェンキンスの家もたくさんのスペースを使っています。

マスタービルド（debパッケージとWebサイトビルドを含む完全なパイプライン）は、すべてが緑色に見えても、どういうわけかまだ失敗しています。 何か案は？

communityへのフォーカルdebパッケージのアップロードは、ファイルelektra_0.9.3.orig.tar.gz失敗します。 これはおそらくファイルのアクセス許可の問題です。 今のところディレクトリから削除し、次の実行で再作成します。

どういうわけか、sshPublisherが失敗しても、ステージは赤に設定されません。

たぶん、既存のcronjobを適応させて-aフラグを追加する必要がありますか？

こんな風にやらなかった理由はありますか？ そうでない場合は、良い考えのように聞こえます。

Jenkins CIとa7のレジストリは、ものみの塔のイメージを新しいバージョンに移行するためにオフラインになります。 ほんの数分かかるはずです。

編集：更新が行われ、JenkinsCIが再び稼働します

Jenkinsとエージェントは、更新のために一時的にダウンします。

編集：すべてが更新され、再び稼働しています。 a7がバスターの代わりにDebianストレッチドッカーパッケージを使用していた問題を修正する必要がありました。 スペースも片付けました。

a7スペースがないため、ビルドが失敗しています。

ビルドインフラストラクチャは、メンテナンスのために数分間利用できなくなります。

ビルドインフラストラクチャが再び利用可能になりました。