Libelektra: Сборка сервера

@ markus2330

Просто внесено несколько исправлений, связанных с системой сборки. Но вам также необходимо исправить некоторые пакеты на вашей стабильной стабильной debian машине:

• Пожалуйста, установите qtdeclarative5-dev из wheezy-backports (после этого вы можете удалить /opt/Qt5.3.0)
• Пожалуйста, установите java8 как пакет:
  
  
  
  • Используйте этот метод: http://www.webupd8.org/2014/03/how-to-install-oracle-java-8-in-debian.html
  
  
  • Пусть cmake действительно найдет jdk8: cd /usr/lib/jvm/ && ln -s java-8-oracle default-java
  
  
  • echo -e "/usr/lib/jvm/java-8-oracle/jre/lib/amd64\n/usr/lib/jvm/java-8-oracle/jre/lib/amd64/server" > /etc/ld.so.conf.d/java-8-oracle.conf && ldconfig
  
  
  • kill + перезапустить локальный java-процесс jenkins. В противном случае все сборки выйдут из строя
  
  
  • Необязательно: удалить jdk7
  
  

Выглядит хорошо, спасибо за исправление этих проблем.

Я также проделал эти шаги с агентом debian-stable.

На других машинах установка qtdeclarative5-dev была невозможна, поскольку она конфликтует с qdbus, который необходим kde4. Поэтому я восстановил предыдущий сценарий configure-debian-wheezy как configure-debian-wheezy-local.

Я также добавил шаги установки, которые вы упомянули в качестве примечаний в README.md, потому что они могут быть интересны другим.

Спасибо за обновление агентов!

Вещи, которых не хватает в стабильной версии

1.) латекс (+ думаю тоже нужен текслайв-латекс-рекомендуемый)
см. http://build.libelektra.org : 8080 / job / elektra-doc / 495 / console

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


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

    BUILD_EXAMPLES

2.) Можно ли установить clang (для elektra-clang не работает clang of wheezy)?
3.) Можно ли установить mingw + wine для elektra-gcc-configure-mingw?

apt install --no-install-recommends doxygen-latex + clang + mingw готово

Зачем тебе вино?

Кстати, вы должны изменить i586-mingw32msvc-X на i686-w64-mingw32-X в Toolchain-mingw32.cmake . Сейчас это не сработает на нестабильной версии.

Спасибо за документ!

Wine требуется для выполнения кросс-скомпилированных двоичных файлов Windows (например, exporterrors.exe)

Я думаю, вы установили mingw, который собирает для w64. В пакете mingw32 все еще есть /usr/bin/i586-mingw32msvc-c++ .

Тем не менее, приветствуется новый файл инструментальной цепочки для w64.

Я установил gcc-mingw-w64-i686 это сборка mingw x64 с i686 в качестве цели.
Пакет mingw32-binutils устарел и больше не доступен в нестабильной версии.

Вино установлено на обоих контейнерах.

На самом деле сборка mingw обязана быть стабильной, так что это не должно быть проблемой.

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 довольно особенная.

Изменить: я посмотрю, смогу ли я получить сборку elektra с mingw-w64, поэтому мне не нужно устанавливать тонны библиотек i686.

Проблема в том, что у меня нет запасной машины jessie, а mingw хрипы не знает C ++ 11.

Мне удалось заставить работать mingw-w64. Однако std :: mutex недоступен, потому что в Windows нет glibc, а std :: mutex зависит от pthreads. Любые идеи?

Вау, спасибо!

Это приводит к ошибке компиляции? Std :: mutex не используется для внутренних
функциональность, но только в файле заголовка, который должен быть включен пользователем. Это используется
хотя в тестовых случаях.

Одним из решений проблем компиляции является предоставление std :: mutex в mingw
кейс выдает системные ошибки при каждой попытке блокировки / разблокировки. На самом деле я бы
ожидайте, что люди из mingw, по крайней мере, предоставят что-то подобное (например, когда
установлен какой-то макрос, похожий на -D_GLIBCXX_USE_NANOSLEEP)

https://github.com/meganz/mingw-std-threads может быть другим способом. Но это
скорее всего, полезен только в том случае, если все тестовые примеры, кроме тех, которые включают std :: mutex
уже запущен.

По сути, это только один экземпляр C ++ 11, который не доступен должным образом.

статус mingw прямо сейчас:

• добавлен dlfcn-win32 как внешний проект в libloader. таким образом cmake проверяет + компилирует библиотеку в качестве дополнительного шага сборки. Связываю архив во избежание дополнительных dll deps.
• добавлена ​​зависимость winsock2.h / ws2_32.dll для cpp11_benchmark_thread. требуется gethostname () - вызов

Прямо сейчас я строю с помощью -static-libgcc + -static-libstdc++ . В противном случае Wine не сможет найти библиотеки DLL. Дополнительный мьютекс тоже не компилируется. Я пробовал mingw-std-thread. просто появилось больше ошибок компиляции :-)

Если я переключаюсь с x86_64-w64-mingw32-X на x86_64-w64-mingw32-X-posix std :: mutex компилируется нормально, потому что определен материал pthread. Однако я получаю дополнительную зависимость от libwinpthread-1.dll, которую вино не может найти.

Я думаю, что лучше всего использовать x86_64-w64-mingw32-X-posix .

Опять же, я удивлен, что у вас вообще есть эта проблема. До сих пор мы были счастливы, когда получили libelektra.dll.

Я ничего не могу сказать об этом решении x86_64-w64-mingw32-X-posix , потому что не использую его и не знаю, к чему это приведет. Мне интересно, что такая posix-lib вообще существует, я думал, что подход posix-слоя - это cygwin, а не mingw.

Влияет ли это решение вообще на libelektra.dll? Если это только для тестовых случаев, никто не будет заботиться (пока сервер сборки может его запустить). Если тестовые примеры будут выполнены, это будет огромным преимуществом. (См. №270, где модульные тесты выявили некоторые странные ошибки в Mac OS X)

Похоже, что libwinpthread-1.dll можно скачать, хотя я не знаю, работают ли они с вином? Можете ли вы также добавить его как внешний проект, как это сделано с помощью dlfcn-win32 (чтобы все dll обрабатывались одинаково)? В противном случае, если вам нужно загрузить 1 или 3 библиотеки DLL для тестов, это может не иметь большого значения (опять же, я не пользователь и не понимаю концепцию развертывания, если таковая имеется, DLL Windows).

@beku Что ты думаешь? У вас есть время протестировать нашу последнюю сборку 0.8.13 mingw-w64 в Windows вместе с oyranos?

Обычно включаются ли тесты для задания сборки mingw? Вчера все они отключились.

Да, они были инвалидами. Но такие примеры / тесты, как cpp11_benchmark_thread , тоже были отключены. Итак, я подумал, что вы изменили его и скомпилировали больше, чем это было сделано ранее.

Я скомпилировал все репо с включенным C ++ 11. Больше ничего.

Но исполняемые файлы, такие как bin / basename.exe, созданные с помощью -posix, работают нормально, пока вы копируете необходимые dll в каталог bin (спасибо, Windows за отсутствие RPATH). Я не нашел способа а) позволить cmake найти каталог dll + б) указать Wine на каталог dll.
Я думал, что статическая компоновка будет работать, но потом сборка не удалась из-за повторяющихся символов во время компоновки elektra dll. Потому что в dll уже включены символы.

@ markus2330 Мне удалось заставить elektra скомпилировать с mingw +, работающим с вином, без копирования каких-либо dll. Уловка состоит в том, чтобы всегда включать статическое связывание как для исполняемых, так и для общих объектов ( 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)
[...]

Прямо сейчас я просто добавил версию скрипта, не думая о других компиляторах. Продолжить работу или мне не интересно?

сбой в src / plugins / wresolver / wresolver.c, потому что pk-> filename имеет значение NULL

pk имеет тип resolverHandles.user

Я попытался взглянуть на плагин, но мне не удалось понять цикл for в elektraWresolverOpen . Цикл вызывает elektraWresolveFileName -> elektraResolve{Spec,Dir,User,System} который все malloc resolverHandle->filename и, следовательно, утечка памяти.

Спасибо что подметил это! Код явно не работает с момента введения в c87ae8e87a716b02b2c7ed790ad56a89d95547a9
Только во время цикла и всегда инициализируется системный дескриптор. Это приводило к сбоям при использовании другого пространства имен.

Я исправил это в
edb4d50856bb5331749220de5a83fa2062624a9d

О продолжении работы: с одной стороны, было бы неплохо, если бы скомпилированный материал также работал. С другой стороны, релиз должен произойти в эти выходные, поэтому в ближайшее время будет важен пул-реквест (должен быть, по крайней мере, шанс короткого круга обратной связи, например, что на самом деле делают скрипты версий).

Но имхо этого достаточно, если работает только один вариант (статическая компиляция). Приятно видеть, как работает kdb-tool!

Где я могу найти edb4d50856bb5331749220de5a83fa2062624a9d?

edb4d50856bb5331749220de5a83fa2062624a9d был добавлен немного позже.

Какие версии gcc установлены на debian-unstable-mm?

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 (по умолчанию) в нестабильной версии

Пожалуйста, проведите такие тесты (я считаю их в любом случае совершенно ненужными) на своих собственных контейнерах. Мои все равно не останутся навсегда.

Я этого не читал. У них может быть 50 МБ каждый. Не могли бы вы установить их снова и ответить на первый вопрос?

Может, я сказал вам на нашей встрече. Но я точно тебе сказал.

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 (стабильный) нужно еще несколько пакетов. Не могли бы вы установить:

• [] fakeroot
• [] gpg (+ создать ключ для Autobuilder [email protected])
• [] реппро (возможно, уже установлен, скрипт пока не заходил)

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 доступен для Джесси, а также python-support . Пожалуйста, установите их.

Я тестировал его локально, когда эти пакеты установлены, он собирается для jessie.

Конечно, это доступно, но это неправильная зависимость. python-dev зависит от python2.7-dev, чего _не_ достаточно. Вместо этого требуется python2.7-dev + python3-dev.

поддержка python вообще не требуется imho.

Я не знаю, почему зависимости были выбраны таким образом, большая часть упаковки была сделана @iandonnelly во время gsoc.

Да, пакеты также должны быть обновлены для создания привязок python3. В настоящее время это просто не сделано. Тем не менее, вы можете установить python3-dev, чтобы сборка не прерывалась (когда привязки python3 + плагины добавляются в пакет debian).

Это не значит, что они правы :-) - Я почти уверен в зависимости от python-dev.
Не могли бы вы заменить их и удалить службу поддержки python?

python3-dev и python2.7-dev уже установлены. В противном случае привязка не возникнет.

Кстати. официальный пакет debian от @pinotree строит только для python3. Было бы пустой тратой времени исправлять то, что находится в нашей ветке "debian", работа @pinotree в любом случае лучше.

Когда я найду время, я обновлю нашу ветку «debian» до того, что

Я никогда не говорил, что удалю пакеты python2. Все, что я говорю, это то, что python-dev - неточная зависимость. Нам нужны явные версии. Итак, pythonX-dev - это правильный деп.

Надеюсь, Pinotree правильно выяснил зависимость.

Кстати, гепард мертв. Не используйте это.

Хорошо, заменил. Верните b7c266b36b0ab0fad9120e67a457b580c7c44690 и установите поддержку Python, если она все-таки понадобится.

Уверен, что у пинотри все получилось правильно;)

И там написано: dpkg-checkbuilddeps: Unmet build dependencies: build-essential:native
http://community.markus-raab.org : 8080 / job / elektra-git-buildpackage-jessie / 3 / console

установлены

python-dev - неправильная зависимость. это должен быть python2.7-dev или python3-dev или оба

• python-dev устанавливает пакет разработки для версии Python 2 по умолчанию; начиная с Wheezy, это Python 2.7
• python3-dev устанавливает пакет разработки для версии Python 3 по умолчанию; Python 3.2 в Wheezy, 3.4 в Jessie и пока все еще 3.4 в Stretch (я думаю, скоро будет 3.5)

Итак, если вы хотите создать версию Python 2/3 по умолчанию, используйте соответственно python-dev / python3-dev , а не версии pythonX.Y-dev (которые вам нужно использовать, когда вы явно хотите установить точную версию Python, даже если не единственная, установленная в системе, и не версия по умолчанию). Я рекомендую использовать любой из них.

из python-dev описание:
This package is a dependency package, which depends on Debian's default Python version (currently v2.7).

Согласно этому тексту, python-dev наверняка скоро может зависеть от python3.

Более того: другой версии python2 никогда не будет. Таким образом, python2.7-dev будет последним пакетом python2 dev в истории.

Я сказал, что это зависит от python3-dev.

Теперь не хватает только ключа:

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

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

сделано

Спасибо!

Экспортируйте / home / jenkins / repository через http.

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

→ http://194.117.254.29/elektra-stable/

@manuelm Не могли бы вы установить ronn на агентов? (необходимо для создания страниц руководства)

apt-get install ruby-ronn

сделано

Спасибо, пакеты jessie собираются снова, и теперь включены справочные страницы!

Пожалуйста, установите musl, т.е.

apt-get install musl musl-dev musl-tools

Спасибо!

установлен мусл и обновлены повестки дня

Две важные вещи о сервере сборки:

1. Не создавайте новые пустые задания, а дублируйте их, они имеют правильные настройки (кроме упомянутых в пункте 2).
2. Мы должны использовать эталонные клоны (в / home / jenkins / libelektra) или предпочесть мелкие клоны для каждой работы по сборке (в настоящее время выполняется только для некоторых, например, elektra-clang). В настоящее время трафик коммитов превышает 300 МБ из-за множества ненужных повторных клонов.

@mpranj Было бы здорово, если бы вы

@ markus2330 на всякий elektra-clang ?

Мелкие клоны применяются ко всем заданиям сборки, кроме :

• [] elektra-git-buildpackage-jessie
• [] elektra-git-buildpackage-wheezy
• [] elektra-multiconfig-gcc-стабильный
• [] elektra-multiconfig-gcc-нестабильный
• [] тест-пакет-источника

Эти вакансии отправляются в какой-то подкаталог. Не был уверен, что вам там нужно, поэтому оставлю их пока такими, какие они есть.

Спасибо! Да, им нужна полная история и ветки, мелкие клоны не имеют смысла, но репозиторий эталонных клонов был бы полезен.

Jenkins был обновлен до 1.651.2. Также были обновлены все плагины.

Я оставлю вопрос открытым для репозиториев эталонных клонов. У нас также должны быть «задания cron», которые время от времени обновляют репозитории, в идеале с использованием самого jenkins.

Дженкинс перестал строить некоторые рабочие места (очевидно, с момента обновления). Это терпит неудачу с
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.

Спасибо за информацию. Я пытаюсь понизить версию конструктора запросов github с 1.31 до 1.14.

Теперь кажется, что он застрял при установке статуса сборки для коммита Github. Он предупреждает, что это устарело в конфигурации.

Я также пытался понизить версию каждого плагина с *git* в названии, но затем все еще были ошибки (странная ошибка, связанная с Mailer Plugin, переход на более раннюю версию Mailer Plugin не помог). Поэтому я снова обновил все до последних версий. Проблема, похоже, известна выше по течению:

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

Надеюсь, скоро исправят.

Другой вопрос: кто-нибудь знает, как выполнять несколько заданий для каждого PR? (Я хотел бы запустить как elektra-mergerequests-stable, так и elektra-mergerequests-unstable)

Задание elektra-test-bindings отлично работает с параметризованными сборками (как также описано в заявке на апстрим). Не могли бы мы просто переключить его на параметризованные сборки? Об ошибке сообщалось в апстриме некоторое время, я не думаю, что скоро она будет исправлена.

Хорошая идея, мы могли бы изменить все PR-задания на параметризованные сборки, на самом деле это имеет только преимущества. Это позволяет нам запускать задания вручную, также указав ветку. И его также можно использовать для обычных строительных работ.

В идеале каждая работа могла бы выполняться и PR на github. (За исключением тех, которые предназначены специально для задач, не связанных с связью с общественностью, которые обновляют документ или покрытие основной ветки)

Недостатком конфигурации elektra-test-bindings является то, что она выполняет только опрос и занимает довольно много времени, пока не начнет сборку (до 5 минут). Однако я не хочу активировать «Использовать хуки github для запуска сборки», чтобы не прерывать сборку.

Кстати. Вы уверены, что вариант «мелкий клон» подходит для заданий сборщика запросов на github?

Интересно, как github выбирает работу по сборке, которую он использует для новых PR. Почему elektra-test-bindings и elektra-ini-mergerequests никогда не выбираются для нового PR? Почему иногда elektra-mergerequests-unstable, а иногда elektra-mergerequests (-stable)?

@manuelm у тебя есть идеи?

Кстати. каким-то образом связь завершенных заданий сборки и github сильно нарушена (даже для привязок elektra-test). Теперь почти на каждой сборке написано: «Некоторые проверки еще не завершены».

Недостатком конфигурации 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 действительно беспорядочная.

Кто-то говорил о проектах на github, где для каждого PR выполняется несколько заданий. (Отображается индивидуально)

Что такое подзадание? Вы имеете в виду мультиработу ?

Кто-то говорил о проектах на github, где для каждого PR выполняется несколько заданий. (Отображается индивидуально)

Вам нужно будет добавить две службы на github.

Что такое подзадание? Вы имеете в виду мультиработу?

Ага, мультиработа.

кстати, а как насчет https://docs.travis-ci.com/ ? У Трэвиса есть поддержка OSX.

Я знаю, что он не заменит jenkins, но может заменить PR / при каждой сборке коммита. Дженкинс все еще может выполнять тестирование нескольких компиляторов и т. Д.
Изменить: у Трэвиса даже есть gcc + clang.

Согласны, было бы интересно использовать их мощность / электричество процессора бесплатно, так как elektra имеет открытый исходный код.

Вполне вероятно, что связь между github и jenkins на самом деле составляет 1: 1. В сервисе github я ввел http://build.libelektra.org : 8080 / github-webhook / и не нашел способа создать другой URL-адрес в jenkins. (Я только нашел способ указать переопределение, но это не привело к созданию нового URL-адреса).

В https://github.com/janinko/ghprb/issues/142 они обсуждают, что это должно «просто работать»? (Без добавления нескольких сервисов)

Однако проблема sha1 должна быть решена сейчас. Он был сломан, потому что Дженкинс представил новое измерение безопасности, которое удаляет неизвестные переменные среды. Я зафиксировал его как предложено (добавлено -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, поэтому ничего не могу сказать по этому поводу. Я дал разрешение, что Трэвис имеет доступ к ElektraInitiative.

Первая сборка трэвиса: https://travis-ci.org/ElektraInitiative/libelektra/builds/130425147
Думаю, нам нужен файл yaml, чтобы Трэвис знал, что делать.

И я понял, как выполнять несколько заданий Дженкинса за PR, требовался разный контекст для каждого задания по сборке. На следующей встрече мы обсудим, что должны делать «быстрые» и другие строительные работы.

Я работаю над Трэвисом (или проверяю кое-что)

Повеселись. Трэвис также добавил сервис github, так что я предполагаю, что PR также будет построен с Трэвисом.

Я уже громко ругаюсь

- Не удалось найти JNI (отсутствует: JAVA_AWT_LIBRARY JAVA_JVM_LIBRARY JAVA_INCLUDE_PATH JAVA_INCLUDE_PATH2 JAVA_AWT_INCLUDE_PATH)
- Исключить плагин jni, потому что jni не найден

Я не могу правильно настроить плагин java. Однако привязки Java работают. На debian unstable. Любые идеи? Просмотр модуля 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

Нестабильный Debian собран в контейнере докеров. Но строительство требует времени.
Есть хорошие идеи?

clang часто быстрее в отношении времени сборки, но я думаю, что установка зависимостей - это то, что занимает много времени

Нет ли более минимального образа докера Debian, чем тот, который использовался? Кажется, устанавливается много пакетов, в которых нет необходимости.

@sirblackheart С чего вы так думаете? https://github.com/manuelm/libelektra/blob/a3d4b9212e738f9b8f2c13318b8a661522dff4a6/scripts/docker/Dockerfile.debian_unstable#L6

@manuelm, вероятно, dist-upgrade. обновляется множество пакетов, специфичных для настольных компьютеров, например Wayland

Нет. Дистанционное обновление короткое. может минутку. около 50% времени занимает установка сборки deps.

Я отправляю образ сборки на сайт hub.docker.com прямо сейчас. Надеюсь, это ускорит процесс. Но образ имеет 1,9гб

Истекшее время 14 мин 8 сек

Не уверен, сможем ли мы добиться большего

как я уже сказал, лязг может дать нам 2-3 минуты. по крайней мере, для проекта Aseprite
https://travis-ci.org/aseprite/aseprite

В любом случае было бы полезно иметь оба компилятора.

При подготовке рабочего материала только что пришла идея: что, если мы извлечем пути всех коммитов в push-запросе и создадим привязки / плагины только в том случае, если они затронуты? например

• изменение в cmake / * запускает все (плагины + привязки)
• изменение в src / bindings / foo вызывает привязку foo
• изменение в src / plugins / foo триггеры плагин foo
• изменение во всем не компилирует никаких плагинов + привязок

У нас все еще есть ежедневная / дважды в день полная сборка Дженкинса.

@manuelm хорошая идея, @ tom-wa написал бы такой сценарий, вы можете создать для этого новый выпуск?

@mpranj : Напоминание: добавьте сборки Mac OS X в travis и добавьте сборки mingw в PR. (* BSD вроде бы требует больше усилий)

@ markus2330 теперь я понимаю подход @manuelm docker, travis не будет поддерживать ubuntu 16.04 до следующего года, поэтому докер необходим для получения всех зависимостей, которых нет в ubuntu 14.04 = swig3.0 libsystemd-devel.

Мне жаль, что я не смог присутствовать на встрече сегодня. На работе мы все еще готовим большое развертывание программного обеспечения сегодня, поэтому я не могу покинуть офис. Но в кратчайшие сроки я могу отвечать на электронные письма.

Я начал добавлять сборки OS X для Travis 2 дня назад: https://github.com/manuelm/libelektra/blob/e41ac43a18e5e9f9640a4042a313cc43f2704f65/.travis.yml
Сборка находится здесь: https://travis-ci.org/manuelm/libelektra/builds/130898079
Открывайте здесь:

• [] cryto_openssl не компилируется
• [] тесты привязки не пройдены
• [] нет Java

Я буду рад, если отсюда кто-то возьмется за мою работу. У меня нет OS X, и я жду, когда Трэвис проверит систему OSX, очень быстро подводит итоги.

re: docker: Да, версия Ubuntu по умолчанию для Travis не работает. Даже cmake слишком стар.
Получение загруженного образа докера занимает всего около 3 минут. И добавить больше изображений - не проблема. Так что я думаю, что это хороший способ обойти любые ловушки, которые есть в среде travis linux по умолчанию (или которые могут возникнуть после обновления).

Я не нашел хорошего способа интегрировать различные этапы сборки и тестирования libelektra (cmake + make + make test) с docker (build + run) + travis (before_install, before_script, script). Контейнеры Docker закрываются после завершения команды. Поскольку контейнеры докеров предназначены для выбрасывания, вы не можете продолжить работу после этого. Таким образом, состояние вашего диска / компиляции исчезнет, ​​если вы не смонтируете локальный каталог в контейнер. Продолжу работу над докером на следующей неделе.

@manuelm Отлично, ты продвинулся дальше, чем мы думали. Mac OS X для PR и для каждого коммита была бы действительно замечательной. Многие люди сейчас используют Mac OS X, и я не хочу снова и снова нарушать сборку для них. На сегодняшней встрече @mpranj сказал, что заберет вашу работу. Вы хотите создать PR с помощью файла travis?

Нет, так как после этого файл travis еще нужно изменить. В противном случае он будет собирать только OS X. Я бы предпочел, чтобы @mpranj взял мой файл travis и исправил оставшиеся проблемы, связанные с OSX. Затем я возьму его файл travis, конвертирую его в матричную сборку и интегрирую сборки linux / docker + # 730 (если они будут доступны к тому времени)

PS: пожалуйста, проведите тестирование Travis в репозитории с пространством имен пользователей. Вы будете делать много толчков :-)

Добавлены сборки mingw64 на PR, должны работать. Извините за задержку. Я посмотрю на Трэвиса сегодня!

Есть ли обратная сторона возможности запускать задания сборки с помощью фразы в PR (с помощью Github PR Builder)?

Я хотел бы настроить задания из # 745, чтобы я мог проверить, исправил ли я это, но я могу применить его к большинству / (всем) заданиям сборки.

РЕДАКТИРОВАТЬ: Я бы предпочел не запускать все задания автоматически, у нас уже есть немало.

Я думаю, что это хорошая идея, если мы сможем настроить каждое задание, чтобы оно запускалось с помощью фразы. Я думаю, что есть небольшой недостаток (по крайней мере, для привязок elektra-test): вы должны указать, для какой ветки вы хотите построить, и не можете просто нажать «build job now». Было бы здорово, если бы вы нашли для этого решение.

И вы правы в том, что нам лучше сократить автоматические рабочие места.

На самом деле есть очень простое решение. Мы используем переменную (env) sha1 для построения PR. Параметризованные сборки запрашивают значение независимо от того, установлено значение по умолчанию или нет.

Решение: установите для переменной env sha1 значение master (в самой конфигурации jenkins) и отключите параметризованные сборки. Если нет возражений против установки переменной, это решит именно то, что вы упомянули выше @ markus2330.

Я уже установил его, так что вы можете нажать эту кнопку сборки, например, на elektra-mergerequests и начнется сборка мастера.

Да, это очень хорошее решение, оно мне нравится. Это также позволило бы нам создать ветку выпуска с одним переключателем (если он нам понадобится в будущем). До тех пор «мастер» всегда является правильным выбором, если он не выполняется изнутри PR.

Думаю, это также решит проблему фильтрованной переменной окружения, которая была у нас раньше.

Затем мы также можем подумать об уменьшении количества заданий сборки (без дублирования для заданий -mergerequest bulid) и новой согласованной схеме именования. (Здесь можно сделать предложения.) Может быть одна открытая проблема: в настоящее время мы создаем покрытие, документацию, .. как для PR, так и для мастера, и копируем их в разные места. Если мы объединяем задания на сборку, нам нужен способ различать в главном задании / PR-задания для копирования покрытия, документов в разные места.

Я почти закончил применять это ко всем заданиям (но сервер просто стал очень медленным).
Не применяется к вакансиям, в которых используются символы подстановки ** (документ и некоторые другие, но очень немногие)

Вы всегда можете остановить задания сборки, если захотите поработать над ними, если перезапустите их позже (за исключением времени выпуска). Обычно причиной замедления машины является сам Дженкинс. На данный момент может возникнуть проблема с rsync из резервной копии, но это срочно.

Да, вообще никаких проблем, это нужно сделать, но я сделаю несколько последних проверок.

Новости @ ElektraInitiative / elektradevelopers:

• как уже упоминалось, почти _все_ теперь можно построить из PR и / или нажав только кнопку сборки
• триггерные фразы - это всегда имя задания без префикса elektra- . (например, elektra-clang: jenkins build clang, пожалуйста) Я не менял jenkins build please и другие старые фразы по устаревшим причинам
• сообщение о статусе сборки github всегда точно соответствует имени задания сборки

Спасибо, молодец! Обновите doc / GIT.md, чтобы все знали, какие фразы сейчас работают.

(Я надеюсь, что @mention работает только для одного сообщения, и не все читают каждое сообщение, которое мы здесь пишем)

Mac OS X для сборки xcode 6.1 кажется сломанной:
https://travis-ci.org/ElektraInitiative/libelektra/jobs/138919488

Я запустил повторную сборку для этого, но мне кажется, что это временный сбой Трэвиса.

Можете ли вы задокументировать, как перезапустить сборку для PR? Я не знал, что это возможно.

Непосредственно на travis-ci.org по указанной выше ссылке:

Я сомневаюсь, что это достойно документа, но тем не менее я могу это сделать.
Сборка по-прежнему не работает исключительно из-за git checkout. Я не думаю, что это наша вина.

Ах. Я думаю, вы слили его до того, как сборка была запущена / запущена в первую очередь.
Когда я восстанавливаю другие ранее успешные PR, он тоже ломается.

Это больше проблема Трэвиса, чем что-либо еще.

Хорошо, спасибо за расследование.

@manuelm debian-stable-mm кажется недоступным (как для jenkins, так и для меня из сети TU). Не могли бы вы разобраться?

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

Похоже, кто-то остановил контейнер. Я снова начал.

Между прочим, с завтрашнего утра меня не будет дома до 1 августа. Со мной все еще можно связаться по электронной почте, но ожидаю небольшую задержку.

Спасибо за быстрое исправление! Так что я полагаю, вас тоже не будет здесь на следующих встречах.

Ага

У некоторых заданий есть ошибка:

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

например http://community.markus-raab.org : 8080 / job / elektra-icheck / lastFailedBuild / console http://community.markus-raab.org : 8080 / job / elektra-doc / lastFailedBuild / console

Это могло быть вызвано обновлением Дженкинса или @KurtMi, создавшим kdb_import_man ?

На заметку: необходимо установить cppcms.

Простите за ветку, пиар прямо на странице github.

Так проще ли создавать PR? Разве 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 мы обнаружили еще одну ошибку с пробелами в каталоге сборки, поэтому мы должны добавить глобально (для каждого задания сборки) добавить пробелы в каталог сборки. Я бы предпочел, чтобы мы могли добавить сценарий jenkins-setup который экспортирует некоторые полезные переменные (например, export HOME="$WORKSPACE/user space ) и выполняет

mkdir "build space"
cd "build space"

Кроме того, мы должны создать задания сборки, которые обновляют одно глобальное репо. Индивидуальные задачи см. Выше.

Глобальное репо определенно может помочь снизить пропускную способность. Скрипты сборки в исходном коде также могут быть хорошей идеей, по крайней мере, они будут отслеживаться git.

Я не фанат пробелов в дорожках, но уверен.

Быстрая сборка в passwd не работает?

Работа по быстрой сборке раздражает, я пытаюсь удалить kdberrors.h при каждой сборке и смотрю, будет ли он работать более плавно. В конечном итоге предложение @manuelm в # 730 - лучшее решение: мы должны просто проверить, как обновился источник, и на основе этого провести соответствующие измерения.

Думаю, что # 894 исправляет и быструю сборку, прокомментирую строчку, удаляющую kdberrors.h out.

Некоторые задания не работают, например задание HTML-документа.

@mpranj У тебя есть время посмотреть на это?

@ markus2330 Готово. Остальные сбои сборки не связаны с системой сборки.

@mpranj Спасибо! Что вы сделали, чтобы это исправить? Я думаю, было бы полезно, если бы мы собрали здесь также решения для сборки проблем с серверами.

Я изменил в "Управление исходным кодом"> "Git"
Значение "спецификатора ветвления" с "**" на "$ {sha1}"

Это то, что мы используем и на других работах. Это позволяет запускать сборку кнопкой (по умолчанию ветка - master) или построителем PR github (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

Обе сборки смогли проверить дерево и начать сборку.
Итак: я не могу это воспроизвести.

Одна идея: у Трэвиса были проблемы, когда был PR, и вы объединяли его до того, как Трэвис смог сделать клон. Возможно, что-то подобное произошло с elektra-multiconfig-gcc47-cmake-options поскольку сборка там занимает ~ 3 часа.

Отправка артефактов на doc.libelektra.org снова работает, Jenkins и плагины были обновлены.

Я обновил URL-адрес нового сервера сборки https://build.libelektra.org в веб-перехватчиках github. Так что, надеюсь, следующие PR будут построены снова.

Дом Дженкинса почти заполнен. Это тоже не похоже на создание пиара.

Дом Дженкинса почти заполнен.

Спасибо, я изменил размер.

Это тоже не похоже на создание пиара.

Вы хоть представляете, что здесь может быть не так? Ручной запуск вроде работает?

Публикация документа в doc.libelektra. org: 12025 не удалось построить. Я перезапустил ssh-сервер (в агенте build-homepage), и, похоже, он снова работает.

Кажется, что vserver для * .libelektra.org недоступен. Я сообщил об этом в hetzner.

Причина отключения сетевого подключения от контейнера заключалась в том, что сайт libelektra.org был скомпрометирован. См. # 1505 для получения дополнительной информации.

Было бы здорово, если бы мы могли добавить пакет git-build-package для stretch, появляется все больше и больше мест, где нам понадобятся пакеты debian, созданные для stretch.

@BernhardDenner вы просматривали верхний пост? Есть ли что-то, что можно легко сделать? Есть ли что-то, что нужно учитывать @mpranj при улучшении рабочих мест на сервере сборки в будущем?

По просьбе @sanssecours я (временно) отключил elektra-mergerequests, чтобы PR не всегда получали неправильную ошибку. Кроме того, я добавил для @KurtMi

Дженкинс, пожалуйста, создайте gcc-configure-debian-optimizations

@KurtMi Если вам нужно изменить то, что делает задание сборки, просто измените скрипты / configure-debian-optimizations

@sanssecours теперь также имеет доступ к серверу сборки.

Кстати. вы можете отменить задания, если они все равно заменены другими заданиями (в настоящее время существует большая нагрузка). Только будьте осторожны, чтобы не прерывать работу для активных PR, иначе PR не станет зеленым. (Если вы не перезапустите их с фразой «jenkins build ... please».)

@sanssecours Дженкинс был перезапущен (второй раз). Не могли бы вы задокументировать здесь, если вы устанавливаете новые плагины. (Обновления не нужно документировать).

Здесь также можно сделать запросы на перезапуск.

Я изменил «Тихий период» с 2 на 5, чтобы дать больше времени для объединения нескольких PR и / или подталкивания разных коммитов без повторного построения.

Кроме того, я открыл проблему №1689, описывающую тайм-ауты в сборках (я не добавлял ее сюда из-за длинных сообщений об ошибках).

Я также переместил некоторые устаревшие задачи выше в новый раздел «Устаревшие / нерелевантные проблемы [причина]:».

Я обновил плагины на сервере сборки. Надеюсь, обновления устранят проблемы, которые есть в PR # 1698 и PR # 1692.

@ markus2330 Не могли бы вы перезапустить сервер сборки?

Я обновил Jenkins с 2.73.2 до 2.73.3 и перезапустил Jenkins.

Надеюсь, обновления устранят проблемы, которые есть в PR # 1698 и PR # 1692.

Может быть, это общая проблема, не связанная с этими двумя PR? Надеюсь, теперь это исправлено.

Похоже, JENKINS_HOME почти заполнен 😢.

@ markus2330 👋 Не могли бы вы

• очистите домашний каталог или скажите, как я могу это сделать,
• обновить Jenkins и все устаревшие плагины?

Спасибо, что позвонили мне!

Похоже, в плагине была «уязвимость чтения произвольных файлов», а именно «Плагин безопасности сценария 1.35».

Я обновил все плагины, а также обновил jenkins с 2.73.3 до 2.89.1.

Кроме того, я изменил размер диска с 20 ГБ до 50 ГБ.

Мы должны перезапустить сервер в ближайшее время, есть некоторые не перезапускаемые процессы, на которые могут повлиять обновления библиотеки, которые в настоящий момент могут быть небезопасными (хотя и не связаны с jenkins). @BernhardDenner Можете ли вы выполнить перезагрузку (и

Не стесняйтесь сообщать обо всем, что я сломал во время этих обновлений.

Сервер был загружен 20 и почти не ответил. Мы должны быть осторожны с «jenkins build all please», и в более долгосрочной перспективе мы должны переместить агентов подальше от основного сервера.

Я обновился до Jenkins 2.89.2 и перезапустил сервер. Я сообщу, когда все снова заработает.

Похоже, что все агенты теперь отключены с ошибкой «Хост-ключ сервера не был принят обратным вызовом верификатора».

@BernhardDenner Я видел, что запущено применение марионетки, вы сейчас работаете над настройкой?

Я безуспешно пытался перейти на версию 2.89.1 и 2.73.3: подключение к агентам по-прежнему не работает.

Огромное спасибо @BernhardDenner, который исправил проблему ssh.

Мы должны прекратить обновление 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 Я заметил, что в настройках матрицы конфигурации задания Run each configuration sequentially . Может быть, он будет распространяться автоматически, если мы просто уберем этот флажок, чтобы сразу было построено несколько параметров конфигурации, или вы уже пробовали это?

Нет, я не пробовал, попробуйте.

@ markus2330 судя по очереди сервера сборки, похоже, это

Однако я заметил, что райзен, похоже, не справляется с этой работой. Я думаю, это потому, что он настроен только для обработки заданий, соответствующих его тегам, а сборки multiconfig, похоже, не устанавливают эти теги должным образом на первый взгляд. Поэтому мы должны либо заставить ryzen выполнять все, что возможно, либо установить больше тегов для заданий сборки. Похоже, что ryzen не обрабатывает задания, для которых вообще не установлен тег.

Я применю его к gcc-stable дополнительно после того, как он сработает для gcc-stable-multiconfig

Спасибо!

Однако я заметил, что райзен, похоже, не справляется с этой работой.

Нет, это не так, но он уже выполняет кучу других заданий. Но, может быть, мы сможем сделать так, чтобы v2 сделала это?

Я применим его к gcc-stable дополнительно

сделано

Но, может быть, мы сможем сделать так, чтобы v2 сделала это?

Я настроил v2 и теперь жду только объединения PR # 1806, поэтому я могу разрешить больше сборок, чем один. Я думал, что для него подойдет 8 рабочих мест, так как это 8-ядерный, с -j 2, чтобы также использовать SMT?

Чтобы перезапустить контейнер build-v2 в случае сбоя или перезапуска v2, просто введите. Обратите внимание, что это можно сделать только в том случае, если контейнер уже построен - следуйте этим инструкциям в doc / docker / jenkinsnode / README.md. Затем используйте эту команду для перезапуска после того, как контейнер был создан, но остановился:

docker start build-v2

Кроме того, чтобы перенаправить ssh-соединение нового узла сборки из v2 через a7 во внешний мир, я настроил следующий ssh-туннель на a7 (контейнер докеров отображает свой порт ssh на 22222 на v2):

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

Кроме того, открытый ключ ssh контейнера докеров изменяется при каждой перестройке образа и, следовательно, также должен быть настроен на сервере сборки. В этом нет необходимости, если контейнер только перезапускается. Чтобы узнать это, введите в v2 следующее:

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

Скопируйте только первые две вещи, чтобы алгоритм ключа и сам ключ не копировали эту пользовательскую информацию в конце в конфигурацию ryzen-v2 в jenkins для ключа ssh!

v2 не работает, сообщил я админу. Это довольно странно: a7 и v2 - совершенно новое оборудование, и инциденты случаются довольно часто.

v2, похоже, вернулся, и я перезапустил контейнер сборки там. Надеюсь, теперь у нас снова есть более быстрые сборки. Кроме того, я добавил elektra-haskell в «jenkins build all please», так как я хочу иметь стабильные сборки haskell для моего typechecker, поэтому тестирование - хорошее дополнение.

Кроме того, я хочу оставить здесь примечание, что мы дополнительно хотим создать еще один узел сборки, который позаботится о сборках mm, которые теперь также являются новым узким местом в v2.

Наконец, @ markus2330, я думаю, что проверка bashism point run уже выполнена, так как это один из наших обычных тестов /testscr_check_bashisms.sh .

Все узлы для метки debian-jessie-homepage||homepage и агента сборки debian-wheezy-mr в настоящее время отключены. Не работает перезапуск агентов сборки. Было бы очень хорошо, если бы кто-нибудь с SSH или физическим доступом к этим узлам мог разобраться в этой проблеме.

Я перезапустил vservers, но перезапуск агентов в jenkins не помог с ошибкой «В запрос не был включен действительный крошка». @BernhardDenner У вас есть идея?

Похоже, что версия 2 тоже не работает. Итак, у нас есть 3 нефункциональных агента 😢

v2 вернулся, но мне интересно, почему он всегда отключается? могло ли это быть связано с нашим процессом сборки?

Что касается «недействительной крошки», я тоже это видел, когда пытался перезапустить агент на v2, но когда я просто попробовал снова, это сработало.

v2 вернулся, но мне интересно, почему он всегда отключается? могло ли это быть связано с нашим процессом сборки?

Похоже, это сбой ядра / оборудования (даже sysreq не работает, когда компьютер зависает). Наше использование может вызвать ошибку. Компьютер работал без ошибок несколько месяцев, и за время его использования мы уже трижды вылетали из строя.

Я обновил ядро ​​и очистил X-сервер.

Что касается «недействительной крошки», я тоже это видел, когда пытался перезапустить агент на v2, но когда я просто попробовал снова, это сработало.

Спасибо! Теперь я снова смог запустить агент домашней страницы.

Кроме того, я отключил агент debian-jessie-minimal и его задание сборки. Мы должны создать докер-контейнеры для минимальных заданий, я добавил это как задачу.

Как мы были удивлены вчера, сервер сообщества был отключен, потому что произошел сбой, и неправильный ARP-кеш перенаправил наши IP-адреса на другие серверы. После перезапуска все снова заработало, но синхронизация рейда все еще продолжается. (Это могло быть так медленно из-за высокой нагрузки.)

Сервер сообщества имеет почти постоянную нагрузку 10. На данный момент это 13,20 11,29 9,35. Нам действительно следует сократить количество заданий, выполняемых непосредственно на сервере сообщества, и перенести нагрузку на v1. Есть добровольцы?

Есть обновление Jenkins с 2.89.2 до 2.89.4. К сожалению, я не нашел простого способа просмотреть журнал изменений ( apt-get changelog не работает, потому что это неофициальный пакет). Есть ли причины не делать это обновление?

Журнал изменений в восходящем направлении находится по адресу https://jenkins.io/changelog-stable/.
По-видимому, 2.89.4 содержит исправления безопасности.

Спасибо, что заглянули!

Я обновился до Jenkins 2.89.4, и все снова работает.

После перезагрузки elektrahomepage не запускалась по умолчанию, я изменил это (/ etc / vservers / elektrahomepage / apps / init / mark = default).

Я также активировал задание сборки test-docker.

v2 снова не работает: cry:

Но по крайней мере, а7 сейчас вроде стабильно.

Я установил clang-format-5.0 на a7 и на узел stretch (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

Я думаю, что одно из последних обновлений для сервера сборки сломало 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 - это сервер сборки ryzen , который не может подключиться к GitHub. Я изменил метку для задания сборки с debian на debian-stretch-mr соответственно. Теперь работа по сборке, похоже, снова работает .

ryzen, который не может подключиться к GitHub

Похоже, исправление NetworkManager нашего администратора с "manged = true" не сработало. После перезапуска "/etc/resolv.conf" снова стал свисающей символической ссылкой. Я исправил это снова, GitHub должен быть доступен из ryzen. rzyen v2, к сожалению, все еще недоступен (отсутствует мост ssh).

Наконец-то выпущена Elektra 0.8.22. Я добавлю ссылку на # 676, как только сайт будет построен, создание сайта займет больше часа. Возможно, мы сможем перенести сборку домашней страницы на более быструю машину и скопировать только полученный веб-сайт на свое место.

Я думаю, что нам нужно что-то сделать с сервером, на котором размещается 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, но и все остальное, работающее на этом сервере. Для меня это тоже часто неприемлемо. Вроде слишком мало оперативной памяти. (Используется своп 2GiG)

Причиной может быть Дженкинс, есть десятки процессов Java, которые возглавляют список в htop. В течение долгого времени у нас было достаточно оперативной памяти, и своп почти не использовался, и мы мало что изменили (кроме обновления Jenkins и увеличения количества заданий сборки).

Я предлагаю вообще отказаться от использования сервера сообщества в качестве агента. Для этого нам понадобится v2 обратно, но @ e1528532 кажется занятым. Мы также могли бы арендовать сервер получше, но тогда нам понадобится кто-то, у кого будет время для миграции.

@ markus2330 Не могли бы вы перезапустить сервер сборки? В настоящее время даже простые задания вроде elektra-todo терпят неудачу.

Я перезапустил v2 в воскресенье, но, судя по всему, он уже снова не работает, поэтому мы должны сначала получить стабильную версию v2, прежде чем думать о добавлении в нее других вещей.

Я перезапустил Jenkins и v2. Кажется, что Дженкинс снова работает гладко.

@ e1528532 Туннель ssh по-прежнему не работает. Даже после перезапуска a7 невозможно подключиться к v2.

поэтому мы должны сначала получить v2 стабильную, прежде чем думать о добавлении в нее других вещей.

Основное время простоя было вызвано мостом ssh. Если у v2 были проблемы, он обычно перезапускался в течение дня.
Я удалил остальную часть X-сервера, так что надеюсь, что версия v2 тоже стабильна. Для a7 это казалось уловкой (некоторое время перезапуск не требовался). Однако без нагрузки на v2 (для которой требуется мост ssh) мы не можем точно знать, стабильно ли оно.

Как насчет разделения дискуссий об оборудовании (перезагрузка) и программном обеспечении (обновления Jenkins)?

Кажется, проблема с сетевым подключением между a7 и v2. v2 запущен и работает, но я все еще получаю сообщение «Нет маршрута к хосту». Похоже, я не могу это исправить сегодня.

Сеть v2 не работала, потому что при деинсталляции GNOME также был деинсталлирован сетевой менеджер. Теперь мы исправили сеть (используя / etc / network / interfaces) и обновили BIOS / UEFI до последней версии. Надеюсь, теперь все стабильно.

Кстати. есть еще одно оборудование, которое мы могли бы использовать через мост ssh ... (PCS)

Туннель ssh по-прежнему не работает. Даже после перезапуска a7 невозможно подключиться к v2.

Да, это не было автоматизировано. Теперь я обо всем позаботился. Контейнер докера должен автоматически перезапускаться, если компьютер перезагружается. По крайней мере, я установил флаг --restart на «всегда» в соответствии с https://stackoverflow.com/questions/29603504/how-to-restart-an-existing-docker-container-in-restart-always-mode # 37618747

Кроме того, я создал нового пользователя с именем «ssh-tunnel-a7-v2», у которого нет пароля, установленного как для a7, так и для v2 (поэтому для него отключена аутентификация по паролю). Я создал сертификат ssh для пользователя на a7 и добавил его открытый ключ к известным хостам на v2. Затем я добавил службу systemd в /etc/systemd/system/ssh-tunnel-a7-v2.service которая автоматически открывает туннель ssh как службу systemd в соответствии с https://gist.github.com/guettli/31242c61f00e365bbf5ed08d09cdc006#file -ssh-tunnel-service. Поэтому он также должен работать при перезапуске сервера или сбое соединения ssh и больше не зависит от меня или моего пользователя. Благодаря использованию сертификата для подключений не нужно использовать пароли.

Вдобавок к этому, v2, конечно же, перезапускается с этой новой автоматической конфигурацией. Надеюсь, он переживет следующую аварию (если она будет), теоретически должна, но мы увидим.

Задание сборки test-docker всегда терпит неудачу, если Дженкинс выполняет задание на ryzen v2 :

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 .

.

Ах, я неправильно понял ваше утверждение, как: «Нет способа написать логическое выражение, которое позволяет мне сказать (стабильный &&! Ryzenv2)», не то чтобы вообще не было возможности для ограничения агента.

Может быть, это можно сделать с помощью DSL. Я спрошу Лукаса, знает ли он, что делать.

Привет,

как отмечено @sanssecours ryzen v2 не установлен докер , но он имеет Docker тег.
Для запуска test-docker требуется, чтобы узлы имели тег docker.

Возможные решения: установить докер на узле или удалить тег из узла в jenkins.

Возможные решения: установить докер на узле или удалить тег из узла в jenkins.

Спасибо за решение проблемы. Я только что удалил тег docker из ryzen v2 . Насколько я могу судить, сейчас вроде все работает.

Я обновил описание узла ryzen v2, чтобы отразить, что на самом деле это «всего лишь» контейнер докеров, работающий на v2. Следовательно, почему докер был недоступен, хотя он установлен на v2.

Также добавлен плагин для 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, и узлы докеров были перезапущены, и я могу подключиться к a7.complang.tuwien.ac.at -p 22222, что означает, что все должно быть открыто. Однако почему-то Дженкинс просто показывает мне бесконечное вращающееся колесо по какой-то причине, без тайм-аута, ничего.

Я попробовал свой ручной мост ssh, как и раньше, то же самое. Еще раз перезапустил док-контейнер, то же самое. Так что, честно говоря, я не уверен, что именно сейчас не так, без сообщения об ошибке, единственное, что я нашел, это какой-то парень, у которого, по-видимому, есть аналогичная ошибка (вращающееся колесо, но без сообщения), но нет решения по этому поводу, кроме перезапуска всего мастера Дженкинса узел (который я не пробовал): https://issues.jenkins-ci.org/browse/JENKINS-19465

РЕДАКТИРОВАТЬ: я попробовал один из предложенных обходных путей (сбросьте конфигурацию имени хоста на то, чего не существует, повторно подключитесь, затем Дженкинс поймет, что имя хоста неверно, вернитесь к фактическому имени хоста, затем оно внезапно сработало без каких-либо проблем). Итак, я предполагаю, что эта ошибка произошла вместо чего-то с моей настройкой перезапуска, но давайте подождем следующего сбоя, чтобы быть уверенным в этом;)

@ markus2330, держу пари, вы уже сами это выяснили, но быстрый поиск показал мне, что это может быть связано с конфигурацией c-state: https://bugzilla.kernel.org/show_bug.cgi?id=196683 , есть некоторые предлагаемые обходные пути для этого

Похоже, сервер сборки ryzen не может подключиться к нашему репозиторию :

Не удалось получить с https://github.com/ElektraInitiative/libelektra.git

.

конфиг днс снова болтался. Поскольку я не совсем понимаю, почему это
настроил так, как сейчас, я только восстановил настройки сервера имен и
перезапустил задание сборки докера.

12 марта 2018 года в 17:03 Рене Швайгер [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 там стабилен. Таким образом, один из вариантов - удалить сетевой менеджер и на a7. (и используйте / etc / network / interfaces) Нет причин, по которым v2 и a7 имеют разные настройки, это только из-за небрежного администрирования.

В идеале (в долгосрочной перспективе) мы управляем и тем, и другим с помощью Puppet.

https://bugzilla.kernel.org/show_bug.cgi?id=196683 , есть несколько предлагаемых обходных путей для этого

C6 следует отключить, но мы продолжим расследование.

У нового агента сборки «ryzen v2 docker» нет демона D-Bus, работающего как «debian-stable-mm» .

Может ли кто-нибудь установить / запустить его или сказать мне, какой сценарий настраивает сборки multiconfig-gcc47-cmake-options, чтобы я мог добавить фрагмент, чтобы убедиться, что он запущен?

@ markus2330 Я подозреваю, что, поскольку включены и ifupdown, и networkmanager, они оба лезут друг другу в глаза. отключение одного из двух, безусловно, поможет.

Хорошо, я удалил gnome и network-manager на a7, чтобы обеспечить совместимость с v2.

У нового агента сборки «ryzen v2 docker» нет демона D-Bus, работающего как «debian-stable-mm».

Агент сборки находится в контейнере докеров , надеюсь, @ e1528532 помогут вам запустить там демон dbus.

Спасибо. Это должно быть довольно легко. Я запускаю его в контейнере докера (Ubuntu 17.10 artful, созданный из docs/docker/Dockerfile ) с помощью следующих команд:

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

Сервер сборки ryzen не может снова подключиться к нашему репозиторию 😭.

Извини, это моя вина. Похоже, остановки сетевого менеджера было достаточно, чтобы сломать систему.

Это должно быть исправлено сейчас. Пожалуйста, не стесняйтесь сообщать о любых дальнейших проблемах.

@ markus2330 уверен, что он снова сломался бы при следующей перезагрузке

Я взял на себя смелость переделать файл / etc / network / interfaces (и переместить конфигурацию интерфейсов в /etc/network/interfaces.d)
это в сочетании с деинсталляцией сетевого менеджера, надеюсь, сохранит его стабильность

пожалуйста, просмотрите конфигурацию и, возможно, запустите перезагрузку, чтобы увидеть, работает ли она

@ingwinlu Спасибо за исправление, перезагрузка

Я обнаружил, что удалил слишком много пакетов, поэтому снова установил Java (openjdk 9 headless и default-jre): smile:

@ingwinlu Не могли бы вы запустить dbus на агенте v2? В идеале, пожалуйста, также переместите "/ home / armin / buildelektra-stretch / Dockerfile" в какое-нибудь место, не предназначенное для пользователя.

@ markus2330 мое предложение о том, как продолжить работу со средой сборки, на самом деле предусматривает удаление текущего узла dockercontainer-on-v2 и замену его на узел с поддержкой докеров (т.е. больше не указывающий на контейнер докеров на v2, а указывающий непосредственно на v2) .

После этого мы можем настроить конвейер сборки для сборки самого образа из файлов Docker, зарегистрированных в репозитории, чтобы обеспечить различные среды, необходимые для тестов.

Я могу установить приоритет развертывания образа докера с поддержкой dbus, когда доберусь до него, но я не хотел бы выполнять работу, которая скоро станет неактуальной, если мне не придется.

Да, в этом есть смысл!

Долгосрочная цель v2 заключается в том, что мы должны поделиться им с некоторыми другими контейнерами докеров (не для Elektra), поэтому было бы хорошо, если бы все наши части были виртуализированы таким образом, чтобы они не могли влиять на другие контейнеры докеров. (может быть, рекурсивный докер или Xen?) Мы могли бы / должны сделать то же самое для a7, чтобы иметь идентичные настройки.

Мы продолжим иметь доступ непосредственно к машинам, но мы должны снизить риск того, что Дженкинс может убить машины Docker, к которым он не имеет никакого отношения.

Для некоторых агентов у нас уже есть настройка Puppet. Было бы здорово, если бы мы не обошли его стороной или даже лучше: расширили бы эту настройку для a7 и v2. Я надеюсь, что @BernhardDenner скоро расскажет вам об этом подробнее.

Сервер сборки снова не работает 🙌.

Кстати, мы могли бы перенести обсуждение статуса сервера сборки в обсуждение GitHub Team , поскольку эта тема может быть интересна не всем, кто подписан на эту проблему.

Да, весь сервер не работает, включая сервер сборки: cry: И v2 тоже не работает (независимо). Я перезапустил v2 и изменил параметр C-States в UEFI. Но похоже, что с нашим сервером есть большая проблема. Надеюсь, мы заменим его на лучшее оборудование с большим объемом памяти: cross_fingers:

Обсуждение команды GitHub

Разве все ElektraDevelopers не уведомляются, если мы что-то напишем в обсуждении GitHub Team? В этом выпуске каждый может решить, хочет ли он подписаться.

Для меня все еще остается открытым вопрос, следует ли разделить эту проблему на две части: связанные с оборудованием и связанные с Jenkins.

Разве все ElektraDevelopers не уведомляются, если мы что-то напишем в обсуждении GitHub Team?

Насколько я могу судить, да.

В этом выпуске каждый может решить, хочет ли он подписаться.

Это также верно и для групповых обсуждений .

Сервер сборки снова работает. Изменены настройки:

• xms и xmx, чтобы уменьшить количество сборок мусора, когда в очереди много сборок
• Я заметил, что мы используем опрос scm. Я ограничил опрос до 4 одновременных опросов по всему миру, чтобы, надеюсь, немного уменьшить всплески, которые сервер получает в настоящее время.

РЕДАКТИРОВАТЬ:

* Установите # сборки, чтобы сохранить равным 30 для всех конвейеров, так как в соответствии с несколькими источниками, которые читаются при доступе к webui, и, таким образом, большое количество старых сборок замедляет запросы

Обновите Jenkins до версии ver. 2.107.1

• Обновить военный файл Дженкинса
• Отключите настройку безопасности плагинов Use browser for metadata download как это не позволит обновлять плагины
• Обновите плагины до последних доступных версий

РЕДАКТИРОВАТЬ 2018-03-18:

• Добавлен второй исполнитель для всех узлов, работающих на mm

* лишены приоритетов всех агентов, работающих на mr

Мастер должен быть более отзывчивым под нагрузкой. Build all должен быть ближе к 2h, как к 4h + ранее.

РЕДАКТИРОВАТЬ 2018-03-24:
извините за задержки, напряженная неделя ...

• Добавлено новое задание на jenkinsserver (elektra-jenkinsfile), которое будет запускать Jenkinsfile, найденный в репо (когда он существует)

РЕДАКТИРОВАТЬ 2018-03-28:

• Переделал файл модуля туннеля, теперь он анализирует файлы среды и, таким образом, может быть настроен так, чтобы указывать на несколько целей.
• Добавлен сервер v2 в качестве подчиненного устройства, способного запускать докер
  
  
  
  • добавлен пользователь jenkins в версии 2
  
  
  • установлен openjdk-9 на v2
  
  

РЕДАКТИРОВАТЬ 2018-03-29:

• Исправить настройки ulimit на мастере jenkins

Хотя я почти уверен, что @ingwinlu или кто-то уже занимается этим: похоже, что ryzen v2 неправильно настроен:

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

Run

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

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

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

из https://build.libelektra.org/jenkins/job/elektra-multiconfig-gcc47-cmake-options/185/BUILD_FULL=ON , BUILD_SHARED = ON, BUILD_STATIC = ON, ENABLE_DEBUG = ON, ENABLE_LOGGER = ON / console несколько раз.

Ой, извините. Он не имеет установленного deps и должен действовать только как хост-докер. Я сниму дополнительные флажки.
// РЕДАКТИРОВАТЬ: должно быть выполнено. надеюсь, этого было достаточно
// EDIT2: я также отключил test-docker на данный момент, поскольку он, очевидно, не может найти образы сборки, необходимые для запуска тестов.

Но, черт возьми, вещь быстрая, если она действительно получает что-то, что может построить
// EDIT3: renabled test-docker для запуска только на узлах с тегом docker-prefab и передал этот тег ryzen

К сожалению, проблема оказалась больше, чем ожидалось.

У некоторых заданий узлы жестко запрограммированы. Некоторые теги устарели (стабильны на узлах jessie). Некоторые задания не требовали правильных узлов и выполнялись только на правильном, потому что они выполнялись там один раз раньше и были успешно построены.

Введение нового узла (ryzen v2 native) немного изменило распределение, хотя этого и не должно было быть.

Ожидайте неожиданного поведения, пока все снова не заработает.

Журнал изменений:

• переименованные узлы, <os>-<hostname>-<buildenv>
• отключен elektra-multiconfig-gcc47-cmake-options
  на самом деле он уже довольно давно не работает на подчиненных серверах gcc47, с сочетанием сборки gcc49 или gcc63 в зависимости от того, где это было запланировано. Если он включен, он, вероятно, должен перейти в dockercontainer с поддержкой gcc63 на v2.
• пометил тонны вакансий (возможно, пропустил некоторые из них)
  
  
  
  • elektra-todo требовал stable , но не на всех стабильных узлах было установлено sloccount
  
  
  • еще много подобных случаев
  
  

A7, похоже, не работает

waht [email protected] schrieb am Do., 29 марта 2018, 21:24:

Хотя я почти уверен, что @ingwinlu https://github.com/ingwinlu или
кто-то уже занимается этим: Похоже, ryzen v2 неправильно настроен:

FATAL: не удалось применить тег 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 "Ваше имя"

, чтобы установить идентификатор вашей учетной записи по умолчанию.
Опустите --global, чтобы установить идентификацию только в этом репозитории.

фатальный: пустое имя идентификатора (для [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
.

Вы хотите поработать над этим? Я мог бы перезагрузить его сегодня. В качестве альтернативы наш администратор или я могли бы перезагрузить его во вторник.

Если это не слишком хлопотно. Иначе я не могу работать над своим пиаром по
выходные дни

markus2330 [email protected] schrieb утра сб, 31 марта 2018, 14:33:

Вы хотите поработать над этим? Я мог бы перезагрузить его сегодня. В качестве альтернативы наши
админ или я мог бы перезагрузить его во вторник.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-377689937 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AEOv-qBFg1qYb4kI4wGRkjgEywr4VA0Hks5tj3eegaJpZM4DIApm
.

Хорошо, я перезапустил его, а также отключил C6-State в BIOS / UEFI (был включен). Я также удалил gnome / xorg (я думал, что уже сделал это?).

Кстати. экран был полностью черным, поэтому мы можем только догадываться, в чем причина.

они появляются на a7 каждые 10 минут или около того:

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 latelty.

Отключен раздел valgrind в elektra-ini-mergerequests поскольку он запускался через make run_memcheck

они появляются на А7 каждые 10 минут или около того

Да, мы их уже видели. Когда компьютер был куплен, кто-то действительно проверил, работает ли ECC, и тогда таких ошибок не было. Частота этих ошибок как-то зависит от загрузки системы?

Отключен раздел valgrind в elektra-ini-mergerequests, поскольку он запускался через make run_memcheck

Спасибо, что очистили это.

У меня случаются случайные выбросы (сбой контейнеров, остановка сборки посередине, отключение и т. Д.) На a7 снова без каких-либо «настоящих» журналов. только уже упомянутые исправления памяти.

Спасибо, похоже, что-то не так. И у нас теперь тоже есть неисправимые ошибки:

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

снова идет а7.

на более продуктивном фронте: я установил интерфейс blue ocean для jenkins. Предварительный просмотр

снова идет а7.

Это действительно расстраивает. Я перезапустил машину и снова подключил агентов. Я попрошу нашего администратора заменить оперативную память завтра, так что ждите простоя завтра.

на более продуктивном фронте: я установил интерфейс blue ocean для jenkins. Предварительный просмотр

Выглядит отлично! Может, покажете нам на следующей встрече?

У нашего админа уже выходные. Я перезагружу a7 и сброшу BIOS / UEFI до заводских настроек. Если ошибки продолжатся в течение выходных, он, надеюсь, заменит оперативную память.

РЕДАКТИРОВАТЬ: задание сборки не выполнялось, поэтому задание сборки не было отменено.

РЕДАКТИРОВАТЬ: все снова. Ошибок памяти пока нет.

Выглядит намного лучше. Кто-нибудь смотрел слишком много технических советов linus и разгонял сервер?

Извини, мне пришлось на какое-то время остановить Дженкинса. На сервере была нагрузка 20, и то, что мне нужно было сделать, больше не было возможным (> 1 час ожидания, затем я сдался и остановил Дженкинса).

Возможно ли, что даже не начатым заданиям по сборке потребуется оперативная память? (список очереди был очень длинным) В противном случае локальные задания сборки - лучший кандидат для этих проблем. (Выполнялось 3 локальных задания по сборке)

@ingwinlu В идеале мы ничего не строим на этом сервере. Кроме того, можем ли мы сделать работу сборки зависимой от нагрузки на сервер. (Не запускать задания на сервере с нагрузкой> 5?).

Я начал все заново, но надеюсь, что мы найдем быстрое решение для этого.

Прокачал ВЕРСИЮ и CMPVERSION в настройках системы Jenkins.

@ingwinlu Было бы здорово, если бы у нас были эти настройки также в Jenkinsfile.

@ markus2330 см. 8de9272051fe903a7df08f0abdf18879701f7ac9 для примера того, как добиться этого в файле Jenkins.

Удалено make run_memcheck из следующих целей из-за того, что они не работают какое-то время и, наконец, отображаются в системе сборки благодаря # 1882

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

ограничить запуск elektra-gcc-configure-debian-stretch на узлах: stretch && !mr

Обновить jenkins master до 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

отлично работает с Трэвисом .

Они не тестируют то же самое, что (например) они используют разные версии clang ...

Поскольку эта ветка абсолютно не отслеживается для сообщений об ошибках или более длительных обсуждений, я открою новые проблемы для clang и clang-asan, как только я доберусь до нее.

Они не тестируют то же самое, что (например) они используют разные версии clang ...

Я согласен, хотя Трэвис использует устаревшую версию clang 5.0.0 , версия Clang на elektra-clang-asan является древней ( 3.8.1 ). Я не вижу ценности работы по сборке с поддержкой ASAN для такого старого компилятора.

Я создал # 1919 для неудачного теста "testlib_notification" на "elektra-clang-asan".

Я протестировал сборку all со всеми отключенными mr-агентами, и мастер отлично реагировал, в то время как сборка all со всеми включенными mr-агентами фактически отключила некоторые сборки. Следовательно, # 1866 определенно улучшит ситуацию, если мы сможем избавиться от всех агентов mr (-wheezy, так как это не контейнеризация)

Дальнейшее тестирование показывает, что это в значительной степени только работа по созданию домашней страницы. Я удалил его из build all поэтому он запускается только явно.

Он будет заменен контейнерным раствором.

v2 снова в сети с последней версией BIOS.

Пожалуйста, сообщайте о любых проблемах с сегментом здесь (возможно, неисправен ЦП).

а7 вроде не работает?

4 мая 2018 года в 11:10 markus2330 [email protected] написал:

v2 снова в сети с последней версией BIOS.

Пожалуйста, сообщайте о любых проблемах с сегментом здесь (возможно, неисправен ЦП).

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на 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

Это могло быть что угодно. с неисправного ЦП ryzen на неисправный БП :(

12 мая 2018 года в 14:33 markus2330 [email protected] написал:

Теперь все должно быть в порядке.

Получил в нужный момент, были какие-то логи, пока наконец
полностью замерзла.

Журналы были:

ИНФОРМАЦИЯ: rcu_sched обнаружил зависания процессоров / задач:
...
rcu_sched kthread голодал на 7770 джиффи
Watchdog: BUG soft lockup - CPU # 2 зависает на 22 секунды! [docker-gen]
... (много повторений)
Сторожевой таймер NMI: сторожевой таймер обнаружил жесткую БЛОКИРОВКУ на ЦП 2

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-388552175 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AEOv-roPlXhrY0w_CFAmnRRDjVJgHQhSks5txtaugaJpZM4DIApm
.

О # 1993

@ingwinlu Пожалуйста, отключите задания, если они в настоящее время не работают (или, по крайней мере, не запускайте их по умолчанию или с помощью «jenkins build all please»). У нас должен быть высокий приоритет, чтобы мы не подводили работу в PR, где на самом деле все в порядке. (асан в течение некоторого времени не был хорошей ситуацией)

Если они потерпят неудачу из-за какого-то действия Дженкинса, которое вы сделали, было бы неплохо перезапустить задания: heart: Сказать так здесь, в # 160, тоже нормально.

v2 снова работает с новым процессором!

Пожалуйста, отправляйте много работ на стресс-тестирование: smile:

Кажется, что a7 снова не работает.

Спасибо, снова все встало.

Снова перезапустил а7.

Наличие схемы, которая сбрасывает a7 каждый час, скорее всего, повысит доступность.

когда мы можем ожидать снова увидеть А7 в сети?

a7 снова в сети

v2 снова в сети

Блок питания v2 будет заменен примерно через 1 час.

@ingwinlu, можете ли вы отключить агентов, а затем снова их включить? (Если вы сейчас работаете над этим.)

агенты версии 2 на данный момент отключены

v2 снова работает. В нем новый блок питания. Пожалуйста, отправьте много заданий на стресс-тест машины.

Я обновил плагины jenkins. В результате перезагрузки были частично восстановлены старые узлы jenkins (до того, как они были переименованы), что привело к повреждению сборок повсюду, поскольку репозитории git были сломаны.

Я очистил затронутые репозитории и очистил кешированные контейнеры докеров на всякий случай.

a7 снова не работает, и поэтому сборки на основе докеров снова недоступны.

Я также откатываю обновление до xunit, поскольку оно нарушает ограничения безопасности.

Перезагрузил а7 и переподключил всех агентов.

сборки докеров недоступны, так как a7 снова не работает.

Я перезагрузил сервер и снова подключил агентов.

Думаю, замена a7 - лучший выход, см. # 2020

Я думаю, что это снова не работает, моя последняя фиксация привела к невозможности связаться с a7-debian-stretch: java.lang.InterruptedException

@ e1528532 Спасибо, что написали это здесь! При желании можно также проголосовать в # 2020

Перезапустил а7 и переподключил агентов.
Будем надеяться на лучшее, что в выходные не возникнет никаких проблем.

a7 снова не работает: cry: Удивительно, что почти весь уик-энд он работал. Может быть, рекорд по времени безотказной работы за неделю. Тем не менее, # 2020 не получил много комментариев.

Я перезапустил a7 (он реагировал на sysctl), а кто-то другой запустил jenkins. Все снова работает.

a7 снова упал.

Благодарю вас за информацию! Перезапустил а7 и переподключил агентов.

Есть ли смысл в том, что у нас есть агент «debian-jessie-minimal»? Я думаю, вы можете безопасно удалить его, как только он будет интегрирован в Docker. (и вроде уже есть)

РЕДАКТИРОВАТЬ:
В https://build.libelektra.org/jenkins/computer/a7-debian-stretch/log
и https://build.libelektra.org/jenkins/computer/v2-debian-stretch/log
есть предупреждения:

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

плохие новости. v2 тоже вышла из строя.

РЕДАКТИРОВАТЬ: но я, кажется, могу подключиться к нему через ssh ....
EDIT2: выполнил перезагрузку на v2, но теперь я больше не могу подключиться. все еще пингуется с a7 ...

EDIT3: теперь A7 тоже не работает.

Спасибо за сообщение! Перезагрузил а7 и v2. Надо пересмотреть # 2020.

я думаю, что v2 снова не работает:

Не удается связаться с v2-debian-stretch: java.lang.InterruptedException

С v2 все было хорошо, а вот a7 снова вылетел. Все агенты снова в сети.

v2, похоже, снова не отвечает. pingable от a7, но никакого действия ssh вообще. должен быть btrfs только из-за симптомов. ты можешь все перезагрузить перед тем, как отправиться домой на выходные?

@ingwinlu Спасибо, @waht и я успешно перезагрузили v2, но я не могу подключить агентов («Соединение отклонено (Соединение отклонено)»). Есть идеи, что здесь не так? (работает интерактивный вход по ssh)

ssh работал только без подключения через мост.

после перезапуска службы моста соединение может быть установлено.

похоже, что ssh-туннель действительно оказался в странном неопределенном состоянии и не убил себя. Не уверен, почему он не убил сам себя (включен серверный интервал).

Мне также нужно было вручную очистить все рабочие области на v2, поскольку файловая система была повреждена, и все задания сборки на них завершились неудачно.

а7 вроде не работает. Я не уверен, что смогу перезагрузить его до понедельника.

Я перезапустил a7 и v2. (v2, потому что на a7 были сообщения об ошибках, что он не может создать мост ssh для v2. Но также и после перезапуска v2 возникли те же сообщения об ошибках. Тем не менее, мост ssh, похоже, работает. Возможно, какая-то зависимость (сеть?) отсутствует в скрипты загрузки а7?)

Может быть какая-то зависимость (сеть?) Отсутствует в скриптах загрузки a7

Нет, это там.

он не может создать мост ssh к v2

Я считаю, что это происходит, когда ядро ​​v2 перестает отвечать на запросы (и, следовательно, входящие сетевые соединения не могут быть установлены). Раньше вы упоминали журналы, указывающие на ошибки btrfs на v2.

Я готовлю сервер сборки к выключению, чтобы позже заменить ЦП.

a7 и v2 снова вернулись (a7 с новым процессором, v2 с проверенной корневой файловой системой)

в то время как он продолжал работать в течение дня (с последовательной сборкой), похоже, что a7 снова упал.

Да перезапускаю завтра утром.

Мы должны снова обсудить # 2020.

Перезапустил а7. Это снова было зависание процессора.

a7 снова опустился.

Спасибо, перезапустил. Все агенты снова в сети.

Похоже, что некоторые из узлов debian не работают, и поэтому несколько PRS уже давно ждут начала выполнения теста. Это предназначено?

Похоже, что некоторые из узлов debian не работают, и поэтому несколько PRS уже давно ждут начала выполнения теста. Это предназначено?

Во время обновления на узле mm-debian-unstable машина перестала отвечать, и с тех пор мы не могли подключиться к ней. Поскольку владелец не отвечает на наши электронные письма, вероятно, он исчезнет навсегда.

Хотя мы уже перенесли большое количество заданий сборки в новую систему, отсутствуют те, которые в настоящее время находятся в очереди.

Я отключил затронутые вакансии и пометил их как подлежащие замене + удалению из документации

@ingwinlu Спасибо, что позаботились об этом!

Чтение тестов xdg очень важно, если кто-то хочет работать над резолвером. Я добавил это в верхний пост здесь. Можете ли вы обновить то, что вы уже достигли, в контрольном списке выше?

На этот раз счастливый победитель - v2.

@ markus2330 я убрал верхний пост.

Спасибо за уборку! Завтра утром перезагружу v2 (а может и а7, посмотрим).

Перезагрузил. Ни реакции, ни сообщения. См. # 2020

Пожалуйста, перезагрузите a7 и v2.

Перезагрузил а7. Проблем с v2 не обнаружил, все равно перезагружать?

i7 теперь доступен по адресу 192.168.173.96, не могли бы вы создать к нему мост через a7?

Вам необходимо создать пользователя ssh-tunnel-a7-v2 на машине или создать для меня учетную запись.

Мы добавили дополнительный подчиненный сервер сборки i7-debian-stretch , который поможет с libelektra buildjobs.

v2-docker-buildelektra-stretch (offline) как там больше не запланировано никаких сборок. Также отключен ssh-bridge на a7, открывший агент.

Привет @ingwinlu!
как обсуждалось на последней встрече, мне понадобится точка доступа.
Не могли бы вы прислать мне информацию по электронной почте, мой адрес электронной почты находится в AUTHORS.md .
Кстати. нигде не нашел свой адрес электронной почты, возможно, вам стоит добавить себя в этот файл.

Наш сервер сборки v2 будет отключен до 31.07 09:00, так как мы проводим на нем тесты. Ожидайте более длительного времени сборки.

Извините за беспокойство.

// РЕДАКТИРОВАТЬ: увеличенное время простоя на 2 часа

Похоже, что расширение тоже прошло. Было бы хорошо вернуть быстрые сборки после обеда (около 13:00). :улыбка:

mm-debian-unstable был обновлен и снова в сети. Есть ли задания, которые мы можем повторно активировать и закрепить на сервере?

Кажется, что диск i7 заполнен. Моя работа терпит неудачу с No space left on device ( Работа и Работа )

Кстати, мне очень нравится новый интерфейс сборки (dockerization и jenkinsfile). Очень полезно для воспроизведения ошибок сборки.

Спасибо за сообщение!

К сожалению, изменение размера потребует перезапуска (rootfs нужно сделать меньше, прежде чем можно будет расширить другой) и принесет только 20G. Я удалил папки сборки Jenkins, но они были крошечными, так что мы все еще на уровне 99%.

Так что очистка _docker будет более эффективной:
@ingwinlu похоже, что оба _docker / overlay2 огромны. Есть идеи, почему все это было собрано там?

Я принудительно очищаю артефакты докеров с помощью docker system prune -fa . Этот
очистил около 190 ГБ пространства, используемого в образах докеров.

В понедельник, 13 августа 2018 г., в 07:54, 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?

Daily делает нечто подобное, но менее агрессивно. Придется взять другой
посмотри, когда я вернусь в Вену.

markus2330 [email protected] schrieb am Mo., 13 августа 2018, 09:22:

Спасибо!

Можем ли мы поместить это в libelektra-daily или в cronjob?

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/ElektraInitiative/libelektra/issues/160#issuecomment-412430076 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/AEOv-mO_0_b9gGl82qc56LbMRRiIC7Mhks5uQSkzgaJpZM4DIApm
.

Как вы могли заметить, сервер сборки не работал утром (возможно, ночью). Блок питания был поврежден и сейчас заменен.

Кроме того, на следующей неделе a7 или v2 могут быть отключены для тестов на короткое время. Вы увидите офлайн-сообщение "Benchmark", если Anton запустит тесты. Если компьютер остается в автономном режиме слишком долго (например, более одного дня), свяжитесь с нами. (Тогда могло быть забыли снова переключить его в онлайн.)

Решена проблема с нашим изображением sid.

testkdb_allplugins segfault в нашем образе sid во время тестов debian-unstable-full-clang, но только при выполнении на v2. Я вручную обновил образ, чтобы использовать последние доступные пакеты, и поместил его в наш реестр.

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/242/pipeline/411/ пройден, но мы будем следить за этим.

Проблема упоминалась в № 2216 и № 2215 ( @mpranj @sanssecours).

Я реализовал публичный доступ к нашему реестру докеров. Смотрите здесь некоторую документацию о том, как получить к нему доступ.

Сообщите мне, если что-то не сработает должным образом.

// РЕДАКТИРОВАТЬ. Кажется, что нажатие не работает, даже если вход в систему прошел успешно.
// Публичный доступ EDIT2 снова отключен. https://github.com/moby/moby/issues/18569. восстановлена ​​функциональность для сборки системы
// EDIT3: публичное репо снова открыто на hub-public.libelektra.org

Антон хочет заменить материнскую плату компьютера, на котором гиперпоточность отключена в следующий вторник или среду (мы можем выбрать). Кому-нибудь понадобится buildserver в один из этих двух дней?

Я перезапустил реестр докеров и запустил очистку вручную. Надеюсь, это решило любые проблемы сборки с изображением веб-сайта.

@ingwinlu спасибо за ремонтные работы!

К сожалению, этап WebUI дает сбой довольно надежно, например 321 или 320 (сбой даже раньше, но также и при извлечении WebUI?).

Я все больше убеждаюсь, что отменять работу мастера - плохая идея. У нас почти нет успешных сборок на мастере, потому что сборки либо отменены, либо не работают из-за проблем с сетью. В истории коммитов трудно сказать, что произошло, потому что в любом случае они просто отображаются как неудачные.

В качестве обходного пути я отключил ненадежные этапы в c3b59ecef95287ffc33b094b37e03d0ec6b5710f, но я надеюсь, что мы сможем снова их включить!

Должен ли a7-debian-stretch прежнему находиться в автономном режиме для тестов? (отключено с 21 февраля 2019 г., 10:47:56)

Спасибо за сообщение! Похоже, Антон забыл реактивировать. Я снова активировал узел, а также удалил старые узлы (кроме мм, поскольку они все еще работают).

Утром был простой нашего сервера. Все снова работает, но мы получили предложение обменять оборудование. Так что, скорее всего, сегодня у нас будет еще один простой около часа.

Сервер снова работает. К сожалению, у нас такое же оборудование. Если у кого-то есть время для установки / настройки, мы можем обновить оборудование.

Похоже, сборки Jenkins довольно медленные (несколько часов для полной сборки). Насколько я могу судить, только a7-debian-stretch и i7-debian выполняют тесты, в то время как все остальные узлы простаивают. Это ожидаемое поведение?

Спасибо, что сообщили об этой проблеме!

Нет, это не ожидаемое поведение. Похоже, что v2 не работает. Я перезагружу его как можно скорее.

v2 должен быть снова запущен

v2 не работает, и я боюсь, что так будет до понедельника. До тех пор сборка будет очень медленной.

v2 снова с новой материнской платой

Я обновлю все 3 агента сборки (i7, v2, a7, в указанном порядке) до Buster, чтобы избежать # 2852

Я постараюсь свести время простоя к минимуму. Задания сборки могут завершиться ошибкой, перезапустите их (после того, как агенты снова заработают).

i7-debian-buster, бывший i7-debian-stretch снова в сети

v2 следующий

v2-debian-buster и a7-debian buster также снова в сети

Я перезапустил предыдущее успешное задание сборки на мастере, чтобы проверить, все ли снова работает:
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/master/853/pipeline

Кроме того, я добавил PR https://github.com/ElektraInitiative/libelektra/pull/2876, чтобы включить задания сборки buster.

v2, похоже, не работает (также не удается установить соединение ssh), к сожалению, я не в Вене. Надеюсь, наш сисадмин завтра исправит.

a7 теперь также не работает, а вместе с ним и i7 (который подключен через мост через a7).

Таким образом, в настоящее время сборка невозможна. Я связался с администратором.

Все серверы снова включены. Пожалуйста, перезапустите сборки, нажав новые коммиты или написав «jenkins build libelektra, пожалуйста» в качестве комментария к вашему PR.

Техническое примечание: a7 вышел из строя из-за "мягкой блокировки сторожевого пса". Пытался добавить "nomodeset nmi_watchdog = 0". Будем надеяться, что они снова не станут такими же нестабильными, как раньше.

a7 (а также v2 и i7, потому что они подключены через мост через a7) не работают. Я связался с нашим админом. Пожалуйста, постарайтесь не запускать сборки сейчас, так как это приведет только к длинной очереди.

a7 снова в сети (был уже вчера), v2 не пострадал

Согласно странице состояния сервера сборки, серверы:

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

упали. Каталог данных Jenkins тоже кажется довольно полным. И пока мы это делаем: было бы здорово, если бы мы могли обновить Jenkins и его плагины. Я заинтересован в устранении этих проблем. Однако есть две проблемы.

1. У меня нет большого (или вообще никакого) опыта администрирования серверов.
2. Мне, вероятно, понадобится физический доступ к машинам, поскольку они кажутся довольно нестабильными.

a7 - это мост к i7 и v2, поэтому, когда a7 не работает, мы не знаем о i7 и v2.

Доступ не проблема, я могу вам его передать. Но вы должны знать, что обновление Jenkins - это большая операция, поскольку обычно требуется перенастроить Jenkins (в соответствии с примечаниями к выпуску, которых много, поскольку мы не обновляли некоторое время) и исправить Jenkinsfile (в соответствии с изменениями API из плагинов ). Напишите мне, если вам нужен доступ.

a7 (и все остальные) снова вверх.

а7 снова не работает, связался с админом.

Техническое примечание: a7 вышел из строя из-за "мягкой блокировки сторожевого пса".

Быстрый поиск предполагает, что это может быть проблема BIOS. Кто-нибудь проверял, доступны ли обновления BIOS?

a7 - это мост к i7 и v2, поэтому, когда a7 не работает, мы не знаем о i7 и v2.

Это похоже на плохой дизайн. Есть ли способ обойти это?

Быстрый поиск предполагает, что это может быть проблема BIOS. Кто-нибудь проверял, доступны ли обновления BIOS?

Мы установили новый BIOS, заменили процессор и обновили ядро ​​(см. Сообщения выше). С тех пор система работала стабильно. Теперь после обновления до Debian buster он снова работает нестабильно.

Тем не менее, я спросил администратора, доступен ли новый BIOS.

Это похоже на плохой дизайн. Есть ли способ обойти это?

i7 и v2 находятся в частной сети, так как не хватает адресов IPv4. Я спросил нашего администратора, возможно ли настроить IPv6.

Я спросил нашего администратора, возможно ли настроить IPv6.

На самом деле IPv6 нам не нужен, достаточно было бы использовать в качестве моста другой, более стабильный сервер.

Скорее всего, v2 так же нестабильна, как и a7 (был только один сбой, но это мало что говорит, потому что сразу после смерти a7 он берет на себя нагрузку v2). Мы могли бы использовать i7 в качестве моста. Но если v2 и a7 выйдут из строя, i7 также не будет особо полезен, на завершение работы по сборке потребуется много часов. Кроме того, на i7 не хватает места для реестра докеров.

Так что это изменение потребует больших усилий и небольшой выгоды.

Гораздо перспективнее исправить актуальную проблему a7 и v2.

Кроме того, на i7 не хватает места для реестра докеров.

В этом случае единственное решение - исправить a7.

К сожалению, а7 снова не работает: cry:

Я попытался загрузиться со старым ядром, но это не помогло.

Для BIOS доступны и другие версии, но, согласно их примечаниям к выпуску, мало надежды на то, что они решат эту проблему, и нет возможности снова перейти на более раннюю версию, если ситуация станет хуже ...

BIOS для a7 в настоящее время обновлен. Кроме того, мы постараемся использовать более новое ядро ​​из бэкпортов.

Надеюсь, скоро снова появится a7.

Новый биос не помог, теперь а7 вылетал за считанные минуты.

а7 снова не работает, связался с админом. Новое ядро ​​из бэкпортов будет проверено при следующей перезагрузке.

a7 снова поднялся с ядром 5.2

Я думаю, он снова разбился ...

Мы по-прежнему получаем те же сообщения об ошибках или есть хоть какие-то изменения?

Да, опять а7 даун, доложил админу. Он сообщит нам о сообщениях при перезапуске.

Есть ли у кого-то другая идея? (Мы уже обновили BIOS и ядро.)

Некоторые источники предполагают проблемы с драйвером новой графики и что мы должны попробовать nouveau.modeset=0 (чем-то отличается от nomodeset ). Также предлагалось отключить "C-состояния" в BIOS.

Да, опять а7 даун, доложил админу. Он сообщит нам о сообщениях при перезапуске.

Есть ли у кого-то другая идея? (Мы уже обновили BIOS и ядро.)

возможно, отключите a7 в качестве ведомого устройства jenkins, чтобы определить, происходит ли это только при «реальной» нагрузке на машину.

@ingwinlu спасибо, хорошая идея. Я сократил теперь до одной работы по сборке a7 (было 2). На выходные (как только администратор уйдет из офиса) я полностью отключу агент.

@kodebach : спасибо,

Есть ли какие-то сроки, когда снова появится a7?

a7 снова работает, с отключенной гиперпоточностью и только с одним параллельным заданием сборки.

Мы также могли бы снять часть нагрузки с a7, переместив сборки alpine и ubuntu-xenial в Cirrus. Оба они представляют собой простые запуски «сборки и тестирования». Они не делают ничего особенного, вроде репортажей.

Cirrus допускает 8 одновременных сборок Linux для каждого пользователя . В настоящее время сборка linkchecker - единственная сборка Linux на Cirrus.

На самом деле ubuntu-xenial немного избыточно, поскольку наши сборки Travis работают на Ubuntu Xenial.

Спасибо за советы, но мы не планируем выгружать какие-либо Linux-сборки из Jenkins. Напротив, @Mistreated будет работать над улучшением нашей инфраструктуры Jenkins, чтобы сделать ее еще более актуальной и полезной (например, путем создания большего количества пакетов). Преимущества нашего Jenkins:

1. у нас это полностью под нашим контролем
2. мы можем легко масштабировать его (для агентов сборки требуется только Java + Docker)
3. Jenkinsfile очень аккуратный и (по большей части) довольно легко расширяемый

Но, конечно, каждый может также расширить Cirrus (или любую другую дополнительную систему сборки, которая предлагается бесплатно, см. # 1540).

Это было просто временное решение, чтобы противодействовать отключению гиперпоточности и ограничению до 1 одновременного задания на a7.

a7 строит только небольшую часть (около 2/5), поэтому уменьшение вдвое должно быть едва заметным. Или сейчас есть какие-то конкретные проблемы? (На данный момент, конечно, нужно время, чтобы наверстать упущенное из-за простоя.)

a7 строит только небольшую часть (около 2/5)

2/5 - 40%. Я бы не стал считать это мелочью.

Или сейчас есть какие-то конкретные проблемы?

Нет, на самом деле вроде работает лучше, чем раньше.

Извините, я имел в виду около 2/6 (1/6 - i7, 3/6 - v2). И эта часть не удаляется, а только уменьшается.

Нет, на самом деле вроде работает лучше, чем раньше.

Идеально!

Похоже , снова а7 не работает 😭.

Спасибо! Я сообщил об этом.

В будущем было бы отлично, если бы тот, кто обнаружил первый, мог напрямую сообщить об этом

Герберт на Complang.tuwien.ac.at

Достаточно сказать, что «a7 ist leider nicht erreichbar».

А затем также сообщите об этом здесь, чтобы Герберт не получил несколько писем.

Конечно, есть способ заставить главный сервер Jenkins автоматически отправлять такое электронное письмо и, возможно, также публиковать его в этой проблеме GitHub. Было бы очень странно, если бы не было плагина Jenkins для такой простой задачи ...

Да, есть https://wiki.jenkins.io/display/JENKINS/Mail+Watcher+Plugin, но я не уверен, что он делает именно то, что мы хотим. Он также может отправлять электронные письма, когда кто-то намеренно отключает агента. А личная электронная почта с большей вероятностью будет обработана администратором быстрее.

Если что-то автоматизировать, то непосредственно перезагрузку ПК, если они недоступны (может быть, у них вообще какой-то встроенный сторожевой таймер?)

a7 был перезапущен, а «глобальный контроль состояния C» отключен.

Однако он не работает в качестве агента сборки.

Посмотрим, не вылетает ли он без нагрузки. v2 и i7 снова работают.

Администратор (Герберт) будет недоступен завтра, поэтому я пока не использую a7 в качестве агента сборки.

Мой план (если раньше не было протестов или вылетов a7) - завтра включить a7 в качестве агента сборки. Если а7 снова выйдет из строя, Герберт может перезапустить а7 в пятницу. Это нормально?

Если очередь не слишком длинная, я думаю, нам следует оставить агент сборки на a7 отключенным еще немного. Последняя авария произошла через 3 дня. Если мы включим его завтра, мы не узнаем, вызвал ли агент сборки сбой, если только он не выйдет из строя до этого.

Хорошо, тогда давайте посмотрим, как выглядит размер очереди.

Я надеюсь, что «глобальный контроль C-состояния» наконец-то решит проблему, и я думаю, что нам нужна высокая нагрузка, чтобы проверить это.

Очередь была очень длинной, и все основные сборки зависали, так как им нужен a7 для развертывания веб-сайта.

Итак, я снова запустил агент a7.

Некоторые из недавних заданий сборки Jenkins были отменены из-за отсутствия дискового пространства на главном сервере сборки. Я освободил место, удалив журналы старых заданий по сборке. Обратите внимание, что я мог также удалить некоторые файлы журналов новых заданий сборки. В некоторых случаях сборка Jenkins для вашего последнего коммита могла дать сбой, и теперь вы видите только сообщение об ошибке 404. В таком случае, пожалуйста, либо

• используйте jenkins build libelektra please в комментарии под PR, чтобы перезапустить сборку Jenkins, или
• перепишите последнюю фиксацию без изменений (например, используя git commit --amend ) и выполните принудительное нажатие

. Извините за беспокойство.

Спасибо за поддержку!

Я пометил узел v2-debian-buster как временно отключенный , так как он работает некорректно. Дополнительные сведения см. В выпуске № 2995 (и № 2994).

Спасибо, что искали инфраструктуру!

v2 не хватило места на диске. Я выполнил docker system prune Общее освобожденное пространство: 58,37 ГБ

Затем я перезагрузил v2 и снова подключил агент.

Теперь я выполнил du -h | sort -h чтобы найти другие файлы, которые нужно удалить.

Я снова начал v2 с новой версией Docker. Пожалуйста, немедленно сообщайте о сломанных сборках.

Я переустановил докер, очистил все конфигурации и удалил / var / lib / docker. Надеюсь, это исправит.

Версия 2 будет включена снова. Немедленно сообщайте о сломанных сборках.

Как было предложено здесь, я выполнил

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-ce теперь везде 5:19.03.1~3-0~debian-buster

Пожалуйста, немедленно сообщайте о сломанных сборках.

Похоже, сборка master снова завершилась неудачно из-за проблем с подключением к v2-debian-buster (см. Также проблему № 2995).

Попросил нашего админа посмотреть на переключение между a7 / v2 / i7. Я отключил пока v2 и i7.

Я перезапустил libelektra / master и libelektra-daily.

Поменяли порты на всех 3 ПК.

Затем я удалил jenkins homedir на v2 / i7 и перезапустил агент v2 / i7.

Похоже, на v2-debian-buster больше нет свободного места :

Статус выхода ApplyLayer 1 stdout: stderr: write /app/kdb/build/src/tools/kdb/CMakeFiles/kdb-objects.dir/gen/template.cpp.o: на устройстве не осталось места

.

Спасибо за сообщение, я сделал (намного) больше места на v2.

Удаление работы завершено:

Используемый размер файловой системы Доступность% Установлено на
/ dev / sda3 417 ГБ 227 ГБ 164 ГБ 58% /

buildserver не работает из-за миграции (так что мы получаем согласованное состояние в резервной копии нового buildserver)

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]

Надеюсь, мы сможем выполнить миграцию в ближайшее время в начале следующей недели (

В настоящее время сервер выполняет повторную синхронизацию рейда, поэтому ожидайте, что это будет очень медленно.

Сборки Jenkins больше не выполняются, см. №3035.

Дженкинс начал снова. Пожалуйста, повторите сборку Дженкинса.

Похоже, v2-debian-buster не в сети:

Открытие SSH-соединения с a7.complang.tuwien.ac.at:22221.
В соединении отказано (В соединении отказано)

.

Спасибо, я связался с нашим админом, но боюсь, что его уже не будет на работе.

Герберт вчера уже перезапустил v2. Он отключил "одновременную многопоточность".

Если сервер (v2, i7, a7) снова выйдет из строя, также свяжитесь напрямую с нашим администратором через «herbert at Complang.tuwien.ac.at». Пожалуйста, также сообщите здесь, чтобы избежать многократных писем.

Я думаю, что что-то не так с репозиторием Git для ветки master на v2-debian-buster :

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

. Я уже трижды перезапускал сборку, но у Дженкинса всегда возникает одна и та же ошибка.

К сожалению, в v2 есть btrfs, который иногда может повредить файлы. Похожая проблема у нас уже была с отказавшим docker pull . В данном случае файл 0bc3ca6fcbc610abd845aeff5f666938d24117 кажется поврежденным. При запуске md5sum для экземпляров этого файла я получаю:

b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
b9303a311bc8083deb57d9e5c70cde20  ./workspace/libelektra_PR-3038-NAC3HXDHQFTZWU7UCEHHPY5AOGDLHXYBZKKVUYJHDQR3VY4E7S4A@2/libelektra/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117
d41d8cd98f00b204e9800998ecf8427e  ./workspace/libelektra_master-Q2SIBK3KE2NBEMJ4WVGJXAXCSCB77DUBUULVLZDKHQEV3WNDXBMA@2/.git/objects/9c/0bc3ca6fcbc610abd845aeff5f666938d24117

Теперь я удалил весь каталог для мастера и перезапустил сборку. См. Также # 3054

Поскольку я сейчас недоступен в течение нескольких дней, пожалуйста, свяжитесь с "herbert at Complang.tuwien.ac.at" по вопросам, касающимся недоступности a7 / i7 / v2. @Mistreated будет нести ответственность за все, что не связано с перезагрузкой серверов. (Надеюсь, скоро мы получим новый агент сборки.)

Пожалуйста, также всегда сообщайте здесь, чтобы избежать многократных писем и чтобы у всех был хороший обзор того, что происходит.

Есть ли на сервере сборки неисправность?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3062/11/pipeline

Есть ли на сервере сборки неисправность?

Похоже, что основной сервер сборки Jenkins не может подключить i7 . Я пометил узел как временно отключенный.

Сборка не выполняется в произвольных случаях:
Здесь это было прервано без всякой причины
Здесь тестовый пример не проходит, что не связано с моим PR (я просто добавил дизайнерское решение, не касаясь какого-либо кода)

Здесь это было прервано без всякой причины

Я получил одинаковый код прерывания 143 для двух PR и пока не могу их объяснить. Я перезапустил сборку и надеюсь, что теперь она работает.

Здесь тестовый пример не проходит, что не связано с моим пиаром

Это должно быть исправлено благодаря @sanssecours с # 3103. Пожалуйста, сделайте переустановку в master.

Новый узел Jenkins hetzner-jenkins1 , похоже, работает некорректно . Я пометил узел как временно отключенный.

Я обновил докер на i7 и перезапустил машину. Надеюсь, это решит проблему. Агент снова в сети. Сообщите о проблемах здесь (и / или отключите агент).

В настоящее время на i7 выполняется задание # 3065.

@Mistreated, не могли бы вы отладить hetzner-jenkins1, пожалуйста?

Есть ли возможность на какое-то время легко отключить проверку ссылок?

Это происходило целый день:

doc/tutorials/snippet-sharing-rest-service.md:63:0 http://cppcms.com/wikipp/en/page/apt
doc/tutorials/snippet-sharing-rest-service.md:158:0 http://cppcms.com/wikipp/en/page/cppcms_1x_config
doc/news/2016-12-17_website_release.md:94:0 http://cppcms.com
doc/tutorials/snippet-sharing-rest-service.md:62:0 http://cppcms.com/wikipp/en/page/cppcms_1x_build

Другие PR (последние № 3115, № 3113) также затронуты. По downforeveryoneorjustme ссылки действительно недоступны.

ОБНОВЛЕНИЕ: веб-сайт по-прежнему недоступен. Сделал пиар для этого № 3117.

Есть ли возможность на какое-то время легко отключить проверку ссылок?

Вы можете отключить отдельные ссылки, добавив их в tests / linkchecker.whitelist (как вы уже выяснили)

Я не могу повторно запустить неудачные сборки из Cirrus. См. Https://github.com/ElektraInitiative/libelektra/pull/3113
https://cirrus-ci.com/build/6562476467945472

Кнопка ничего не делает. Есть ли волшебный трюк, чтобы заставить его работать?

edit: либо кто-то что-то изменил, либо 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

.

edit: либо кто-то что-то изменил, либо x`а попытка наконец сработала. Сборка снова запущена! :)

После того, как я увидел ваш комментарий, я тоже нажал кнопку «Restart Failed Build Jobs». Насколько я могу судить, нажатие кнопки действительно перезапустило неудачные задания сборки.

После того, как я увидел ваш комментарий, я тоже нажал кнопку «Restart Failed Build Jobs». Насколько я могу судить, нажатие кнопки действительно перезапустило неудачные задания сборки.

У меня это не сработало, в следующий раз я предоставлю гифку!

Я перезапущу сервер сборки и его узлы. Построение заданий № 3121 и № 3099 необходимо перезапустить, так как у них были задания на мертвых агентах.

У меня это не сработало, в следующий раз я предоставлю гифку!

Вам не нужно предоставлять GIF, так как я вам уже верю 😊.

Похоже, что у Дженкинса проблемы с остановкой, я немного подождал, прежде чем принудительно убить все процессы Java.

Я также обновил докер на всех агентах (на i7 он уже был обновлен).

Дженкинс снова поднялся с интервалом сердцебиения, как предложено в # 2984. Все узлы подключены.

При необходимости перезапустите все задания и сообщайте о любых проблемах здесь.

v2 не работает, я попросил нашего администратора перезапустить.

Я снова включил v2, так как, похоже, он работает, а объем невыполненных сборок достаточно велик.

Возникла проблема со сборкой снова ( hetzner-jenkins1 )?
https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3144/1/pipeline/336

`

Возникла проблема со сборкой снова ( hetzner-jenkins1 )?

Да . Я отключил узел.

Это просто Дисковая квота превышена, не хотелось перебивать с памятью. Я почистил это сейчас. Его снова вверх.

Узел обновлен.

Я увеличил hetzner-jenkins1 до 4 параллельных сборок. Это временная мера, пока там больше ничего не работает.

Я временно уменьшил количество исполнителей на hetzner-jenkins1 с 4 до 2, так как время ожидания набора тестов истекает. Я думаю, это происходит, когда во время выполнения тестов компилируется слишком много заданий. Нам может потребоваться ограничить ресурсы, доступные для одного контейнера, чтобы он не слишком мешал другим заданиям.

Не стесняйтесь исправить это, если считаете, что это был неправильный подход.

РЕДАКТИРОВАТЬ: уменьшено до 1, так как время тестирования все еще истекает, и постоянное восстановление тратит еще больше ресурсов.

@mpranj Спасибо, что

@mistreated , может быть, вы назначили только один процессор или аналогичный? Можете ли вы назначить больше и увеличить количество исполнителей? Аппаратное обеспечение должно быть сильнее, чем v2.

Я отключил i7-debian-buster потому что на диске не осталось места, что приводит к сбою всех сборок. Если у кого-то есть доступ, пожалуйста, очистите что-нибудь и снова включите его.

@mpranj спасибо за отключение!

Извините, где я сейчас нахожусь, ssh заблокирован (брандмауэр некоторых приложений, а также ssh на других портах не работает). Поэтому сейчас я не могу предоставить доступ или выполнить какую-либо очистку.

Поскольку i7 - самый слабый из агентов, в любом случае это может не иметь большого значения.

@Mistreated , может быть, вы назначили только один процессор или аналогичный? Можете ли вы назначить больше и увеличить количество исполнителей? Аппаратное обеспечение должно быть сильнее, чем v2.

Понятия не имею, насколько сильна v2.
В настоящее время jenkins1 использует 4 процессора с 8 памятью и 16 подкачкой. Я могу легко увеличить его, я просто не знаю, до какой точки вы хотите, чтобы я увеличил его.

Замечание для будущих аппаратных решений: кажется, что phoronix проводит тесты компиляции в своих статьях о процессорах (например, Ryzen 7 3700X, Ryzen 9 3900X test, в конце статьи ).

Похоже, что hetzner недавно добавила AMD Ryzen 7 3700X к своим серверам на базе AMD.

Понятия не имею, насколько сильна v2.

@ingwinlu написал об этом в своей диссертации (можно найти в репозитории abgaben lukas_winkler)

В настоящее время jenkins1 использует 4 процессора с 8 памятью и 16 подкачкой. Я могу легко увеличить его, я просто не знаю, до какой точки вы хотите, чтобы я увеличил его.

Пока на сервере больше ничего не работает, вы можете выделить все ресурсы. Позже мы еще можем спуститься (когда переместим Дженкинса).

Я обновил файл 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
• версия 2: / dev / sda3 417 ГБ 255 ГБ 147 ГБ 64% /

Затем я перезапустил агентов.

@Mistreated , пожалуйста, исправьте # 3160, чтобы это не повторялось так быстро. Пожалуйста, исправьте также файл hetzner-jenkins1. На этой машине много ресурсов, совсем не обязательно, чтобы она превышала лимит ресурсов каждый день.

Я не знаю, есть ли хороший способ уменьшить размер диска. Вот почему я не передаю узлу все сразу .. hetzner снова встал.

v2 снова не хватило места, почистил: / dev / sda3 417G 315G 102G 76% /

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log не запускается

Я думаю, что система сборки на данный момент полностью зависла, PR не строятся.

Спасибо за сообщение, я перезапускаю Jenkins и очищаю некоторые файлы по мере заполнения диска.

@Mistreated https://build.libelektra.org/jenkins/computer/hetzner-jenkins1/log не запускается

Агент успешно подключился и онлайн

Полагаю, с hetnzer-jenkins1 теперь все в порядке?

Большое спасибо! Похоже, Дженкинс все еще не реагирует на сборки. v2 и i7 теперь и терпит неудачу с: java.io.IOException: Could not copy slave.jar into '/home/jenkins' on slave .

Дженкинс снова встал, перезапустите задания.

java.io.IOException: не удалось скопировать slave.jar в '/ home / jenkins' на подчиненном сервере.

исправлено (тоже не хватало места)

@Mistreated, пожалуйста, исправьте jenkins-daily, поскольку это делает задачи очистки, которые нам теперь всегда нужно выполнять вручную!

@Mistreated "jenkins build libelektra please" все еще не работает, связано ли это с изменениями веб-хуков?

Возможно, попробуйте сегодня перейти на новый Jenkins, но если у вас не получается, пожалуйста, заставьте старый экземпляр снова работать!

Я запустил сканирование репозитория, теперь, похоже, снова работает «jenkins build libelektra, пожалуйста».

Похоже, что диск заполнен на v2-debian-buster

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

К несчастью. Я пометил v2 как отключенный до разрешения проблемы.

Спасибо за сообщение!

@mpranj Я дал вам доступ, вы можете попробовать очистить, пожалуйста?

Спасибо! Мне кажется, что старые образы докеров тратят много ресурсов. Кроме того, кажется, что btrfs + docker глючит. Docker создает подобтомы btrfs для каждого контейнера и не очищает его после этого. Команда docker system prune -f также не освобождает место.

Я взял v2 и a7 на техническое обслуживание, чтобы освободить ресурсы и сбалансировать btrfs.

не удалось войти в докер

Сборка не может извлекать образы докеров. Что-то происходит с докер-хабом?

Да, извините, с a7 я тоже снес докер хаб. Я отправлю сюда сообщение, когда оно снова появится.

a7 включая докер-хаб, снова работает. Я оставил v2 автономном режиме, потому что он не может войти в хаб для получения изображений?!? Я не знаю, что там не так, я не менял никаких учетных данных или около того, и другие узлы могут войти в систему. Любые идеи?

Btrfs все еще балансирует в фоновом режиме, a7 может быть медленнее еще на час или около того.

@mpranj, спасибо, что

К сожалению, я не знаю учетных данных, надеюсь, @ingwinlu может нам помочь.

Команды, которые я использовал для перебалансировки, были:

Исправьте ошибку, связанную с btrfs:

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

Перебалансируйте фс действительно, на это уходит много времени. Параметр использования можно / нужно настроить, вот что сработало сегодня:

btrfs balance start -dusage=80 /

Учетные данные можно легко изменить, но нам придется регистрировать всех агентов jenkins, которые снова подключаются к концентратору докеров с новыми учетными данными.

Более серьезная проблема заключалась в том, что некоторые контейнеры докеров все еще работали, а удаление системы докеров мало что помогало. Поэтому я снял агентов и освободил все, пока оно было отключено. Там просто валялись ТОННЫ контейнеров.

Да, к сожалению, контейнеры быстро воссоздаются. Я надеюсь, что @Mistreated скоро сможет исправить задание libelektra-daily (оно выполняет docker system prune ).

Я также провел довольно сложную цифровую криминалистику и украл учетные данные хаба. :смеющийся:

v2 снова запущен.

Большое спасибо! : 100: Пожалуйста, пришлите нам учетные данные.

Отправлено. Кстати, я думаю, что a7 , вероятно, медленный только из-за низкой скорости диска, но хорошо, что на нем достаточно места для концентратора докеров. Похоже, что большую часть времени процессор там ничего не делает.

Еще одна мысль: возможно, мы сможем дополнительно выполнять критические задания по очистке за задание cron, чтобы избежать таких ситуаций, как сейчас.

Пожалуйста, пришлите нам учетные данные.

@mpranj Я думаю, что был в этой группе «нас». Я не был в каком-то CC или что-то в этом роде?

@Mistreated, извините, я отправил его Маркусу, но не получил твоего адреса электронной почты. На a7 вы найдете CREDENTIALS.txt в вашем домашнем каталоге.

Мне нужен узел hetzner-jenkins1 для тестирования нового jenkins-server. Я выключу его на старом сервере до завтрашнего утра.

Вы можете легко создать второй hetzner-jenkins2 для тестов. Если это только на эту ночь, все должно быть в порядке.

Еще одна мысль: возможно, мы сможем дополнительно выполнять критические задания по очистке за задание cron, чтобы избежать таких ситуаций, как сейчас.

libelektra-daily выполняет эту очистку, но теперь не работает: # 3160. Если у вас есть идеи по улучшению этой работы, сообщите нам.

Думаю, я был в этой группе «нас». Я не был в каком-то CC или что-то в этом роде?

Да, извините, я забыл сказать mpranj, что «мы» относится к вам.

Я надеюсь, что это нормально, что я оставлю hetzner-jenkins1 на какое-то время, теперь все сборки хороши. Я думаю, что сегодня вечером я смогу полностью запустить сервер.

v2 недоступен, я связался с администратором.

Я надеюсь, что все в порядке, что я оставлю hetzner-jenkins1 на какое-то время, все сборки сейчас в хорошем состоянии. Я думаю, что сегодня вечером я смогу полностью запустить сервер.

Было бы здорово!

v2 недоступен, я связался с админом.

Спасибо, но боюсь, он не ответит раньше понедельника.

v2 получает новое ядро ​​(оно только что разбилось).

i7 также будет перезапущен.

Все 3 сервера (v2, a7, i7) теперь имеют "Linux v2 5.2.0-0.bpo.2-amd64 # 1 SMP Debian 5.2.9-2 ~ bpo10 + 1 (2019-08-25) x86_64 GNU / Linux "

Они включены и в сети, при необходимости перезапустите задания.

Просто примечание:
Я снова просканировал репо с новым сервером. Это могло сделать некоторые ошибки на старом.

Похоже, что master [1] также был построен на новом сервере. Не удалось. При нажатии на статус появляется страница входа в систему [2]. Измените конфигурацию Jenkins, чтобы все можно было просматривать без входа в систему.

Надеюсь, мы скоро сможем перейти на нового Jenkins. Увидеть ошибки от двух разных Jenkins ситуацию не легче: wink:

[1] https://github.com/ElektraInitiative/libelektra/commit/master#
[2] http://95.217.75.163 : 8080 / login? From =% 2Fjob% 2Flibelektra% 2Fjob% 2Fmaster% 2F1% 2Fdisplay% 2Fredirect

@ markus2330 можно ли перезагрузить a7 / v2 удаленно после обновления или есть подводные камни?

Обычно это работает, но если это не срочно, лучше подождать, пока не появится админ. Я могу перезагрузиться во вторник, если вас это устраивает?

Спасибо! Ничего особенного, просто общий вопрос. Это произошло потому, что Debian 10.2 только что был выпущен. Подожду немного с апгрейдами.

Тем не менее, вы можете выполнить обновление (только без перезагрузки). Тогда в случае сбоя у нас уже будет ядро ​​10.2, когда админ нажмет кнопку сброса: wink:

@mpranj, может, вы можете добавить

https://docs.docker.com/storage/storagedriver/btrfs-driver/ рекомендует также перебалансировать btrnfs в задании cron.

Можете ли вы добавить задание cron, которое очищает старые снимки? Или это невозможно без остановки докера?

Я могу добавить задание cron, не останавливая все контейнеры докеров. Возможно, это не все очистит, но мы можем попробовать. Как я уже сказал, иногда контейнеры продолжают работать вечно / до тех пор, пока машина не выйдет из строя. Полная очистка требует, чтобы мы временно отключили агент сборки, после чего мы можем принудительно остановить все контейнеры.

Я также могу добавить ребалансировку как задание cron.

Спасибо, давайте попробуем.

Хозяину не хватает памяти. Я хотел запустить репозиторий сканирования на старом Jenkins, потому что a7 и i7 получают следующую ошибку при извлечении изображений докеров:

не удалось войти в докер

Теперь у меня на новом сервере работают v2 и hetzner-jenkins1.

Хозяину не хватает памяти.

Спасибо за сообщение. Я удалил некоторые старые данные о покрытии и снова включил главный узел. Для всех, у кого есть открытые запросы на вытягивание: перезапустите сборки Jenkins с jenkins build libelektra please . Извините за беспокойство.

В # 3234 @ raphi011 предлагалось:

Я думаю, это действительно срочно, нестабильность и медленность тестов затрудняют, если не делают невозможным, внесение каких-либо изменений, если вам придется ждать так долго, чтобы проверить их.

Я согласен, это действительно срочно, но @Mistreated уже делает то, что может.

Так что, возможно, мы сможем использовать сервер сборки более экономно и строить только в том случае, если мы действительно думаем, что PR будет скоро объединен. Ненужные сборки следует отменить.

Или как насчет (временно) остановки автоматического построения PR при отправке изменений (чтобы сборка запускалась только с jenkins build libelektra please )? @Mistreated вы знаете, как перенастроить Дженкинса для этого (я не нашел варианта)?

У меня также есть ощущение, что jenkins build libelektra please на данный момент не работает, по крайней мере, это не сработало для этой сборки: https://github.com/ElektraInitiative/libelektra/pull/3073 мне пришлось нажать пустая фиксация для запуска конвейера.

Реализована очистка cronjob и обновлено ядро ​​backport на 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

Я отключил i7 для ручной очистки, обновления ядра и докера. Кто-то включил i7 пока я над этим работал. Все снова работает.

@Piankero Я перезапустил вашу сборку.

У меня также есть ощущение, что jenkins build libelektra please в данный момент не работает, по крайней мере, это не сработало для этой сборки: # 3073 мне пришлось нажать пустую фиксацию, чтобы запустить конвейер.

работает сейчас

@Mistreated вы знаете, как перенастроить Дженкинса для этого (я не нашел варианта)?

Я добавил в конфигурацию Jenkins следующее:

Подавить автоматический запуск SCM

Примечание для всех: использование «jenkins build libelektra please» теперь является обязательным, задания сборки не запускаются простым нажатием. Мы сообщим здесь, когда мы вернем эту настройку.

@ Неправильное обращение, спасибо! Посмотрим, достаточно ли этого. Я надеюсь, что при нажатии на master все еще будут запускаться основные сборки?

Тем не менее, иметь узел hetzner было бы очень хорошо. Есть ли проблемы, если узел используется двумя серверами сборки одновременно? Или, если это проблема: не так ли просто клонировать КТ?

@ Неправильное обращение, спасибо! Посмотрим, достаточно ли этого. Я надеюсь, что при нажатии на master все еще будут запускаться основные сборки?

ветка master теперь является исключением из следующего правила:

Подавить автоматический запуск SCM

Что касается

Тем не менее, иметь узел hetzner было бы очень хорошо. Есть ли проблемы, если узел используется двумя серверами сборки одновременно? Или, если это проблема: не так ли просто клонировать КТ?

Я добавил новый CT (hetzner-jenkinsNode3).

не удалось клонировать репо: https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-3073/8/pipeline/634/

может это как-то связано с новым узлом? (Грубое предположение)

может это как-то связано с новым узлом? (Грубое предположение)

эта ошибка на а7

эта ошибка на а7

так ... повторить?

так ... повторить?

да, не думаю, что это повторится снова ..

Я перезапущу его для вас.

@Mistreated Думаю, мы снова можем запускать автоматические сборки. Но сначала посмотрите на № 3160.

есть идеи, почему это не удалось?

go: github.com/google/[email protected]: Get https://proxy.golang.org/github.com/google/uuid/@v/v1.1.1.mod: net/http: TLS handshake timeout

https://build.libelektra.org/jenkins/blue/organizations/jenkins/libelektra/detail/PR-2827/8/pipeline/648

есть идеи, почему это не удалось?

Похоже, это временная проблема, URL-адрес в настоящее время доступен из агентов сборки.

В конечном итоге было бы здорово настроить такие зависимости в образах докеров, чтобы избежать их повторной загрузки для каждой сборки. Это также должно предотвратить сбои сборки из-за временно недоступных пакетов, как вы упомянули выше.

Ну тогда .. jenkins build libelektra please третий

Да, именно по этой причине у нас есть все зависимости прямо в образах докеров. Я создал # 3251

Брал v2 и a7 offline для перезагрузки.

@ markus2330, если есть возможность, включите гиперпоточность на a7 .

v2 снова работает, на a7 все еще идет сборка.

Я взял узлы и добавил их на новый сервер. Я позволю ему пробежать ночь. Завтра я верну узлы, если на новом сервере Jenkins появятся новые ошибки.

hetzner-jenkinsNode3 прежнему будет работать на старом Jenkins.

Завтра я верну узлы, если на новом сервере Jenkins появятся новые ошибки.

Небольшие ошибки сборки не повод возвращаться. В какой-то момент нам нужно исправить ошибки, переход туда и обратно отнимает очень много времени.

Однако препятствием может быть то, что новый сервер недоступен. (Ни один
http://95.217.75.163:8066 ни ssh). Я нажал кнопку включения, давайте посмотрим, перезагрузится ли машина. Однако мы должны выяснить, в чем проблема.

http://95.217.75.163 : 8066

Если есть время, пожалуйста, включите TLS с помощью letsencrypt, чтобы мы не утекали учетные данные и не подвергались различным другим проблемам?

Спасибо за вклад! Я бы посоветовал сделать это сразу после переключения build.libelektra.org. В противном случае у нас есть двойные усилия.

Известна ли эта ошибка ? Caught the following exception: null

Похоже, проверка форматирования завершилась неудачно, и другие сборки были прерваны.

ты прав. какое дерьмовое сообщение об ошибке: P

@Mistreated, не могли бы вы снова активировать автоматическое

@Mistreated, не могли бы вы снова активировать автоматическое

Выполнено.

Я снова займу hetzner-jenkins1 и v2 для нового сервера.

Вам не нужно возвращать его, я надеюсь, мы сможем заменить его сегодня.

Совет: при выполнении такого рода переключений полезно уменьшить TTL записи DNS до необычно низкого значения (например, 60 вместо нынешних 21599 для build.libelektra.org). После того, как изменение будет распространено, оно должно позволить нам переключить запись DNS в течение минуты, а не часов. Если уже слишком поздно, это может помочь очистить кеш DNS от google и opendns, но некоторые люди неизбежно увидят старый ресурс до тех пор, пока не истечет глобальный срок действия кешированных записей.

РЕДАКТИРОВАТЬ: после изменения TTL, очевидно, следует вернуть к некоторому разумному значению, чтобы уменьшить нагрузку на DNS.

Хотя сейчас, может быть, уже слишком поздно, я переключил $TTL 3600 (если нам нужно несколько изменений, пока все не

www-new и build-new уже существуют, указывая на новый сервер.

Теперь я переключился на doc.libelektra.org. @Mistreated исправит публикацию. Я посмотрю на www-new.libelektra.org

https://build-new.libelektra.org/ и https://www-new.libelektra.org/home теперь должны работать.

Я сейчас изменю все записи DNS.

Все записи DNS изменены.

К сожалению, certbot не работает, поскольку он, кажется, общается со старым сервером, но, похоже, это влияет только на загрузку и сообщество (менее используемые URL-адреса).

Надеюсь, во время / после выходных все увидят обновленные имена DNS.

@Mistreated, пожалуйста, обновите публикацию всех артефактов: также для веб-сайта. Пожалуйста, создайте PR, чтобы убедиться, что все работает правильно.

Старый сервер сборки теперь выключен.

Мне нужно перезапустить новый сервер (добавлено новое ядро ​​и сетевой мост).

Сервер снова работает с Linux pve 5.0.21-5-pve.

Я запланировал повторное сканирование всех PR.

сервер отключен из-за неправильной конфигурации / ошибки в pve (/ etc / network / interfaces был удален графическим интерфейсом?).

Ошибка заключалась в том, что переименование сетевых устройств (вызванное моими действиями в графическом интерфейсе) приводило к сбою ядра:

Nov 23 21:32:08 pve kernel: [ 1682.138250] veth4d0199f: renamed from eth0
Nov 23 21:32:19 pve kernel: [ 1693.378374]  __x64_sys_newlstat+0x16/0x20
Nov 23 21:32:19 pve kernel: [ 1693.378380] Code: Bad RIP value.
Nov 23 21:32:19 pve kernel: [ 1693.378382] RDX: 00007fa58b238e20 RSI: 00007fa58b238e20 RDI: 00007fa58ba50d24
Nov 23 21:32:19 pve kernel: [ 1693.378383] R13: 0000000000000294 R14: 00007fa58ba50cc8 R15: 00007ffe65c2b158
Nov 23 21:34:20 pve kernel: [ 1814.210370]  request_wait_answer+0x133/0x210
Nov 23 21:34:20 pve kernel: [ 1814.210374]  fuse_simple_request+0xdd/0x1a0
Nov 23 21:34:20 pve kernel: [ 1814.210378]  ? fuse_permission+0xcf/0x150
Nov 23 21:34:20 pve kernel: [ 1814.210381]  path_lookupat.isra.47+0x6d/0x220
Nov 23 21:34:20 pve kernel: [ 1814.210385]  ? strncpy_from_user+0x57/0x1c0
Nov 23 21:34:20 pve kernel: [ 1814.210388]  __do_sys_newlstat+0x3d/0x70
Nov 23 21:34:20 pve kernel: [ 1814.210392]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

Сервер должен снова заработать.

Однако предыдущие проблемы остались (фраза не работает # 3268)

@Mistreated master, похоже, больше не строится автоматически, теперь я запускаю его вручную.

Собираю срочные ошибки в # 3268. Было бы хорошо, если бы вы также могли проверить, все ли работает, как описано в doc / BUILDSERVER.md.

jenkins не строит без какой-либо причины:
https://github.com/ElektraInitiative/libelektra/pull/3286
https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-3286/3/pipeline

Еще одна ошибка сборки: https://build.libelektra.org/blue/organizations/jenkins/libelektra/detail/PR-2827/13/pipeline

Спасибо за сообщение!

@Mistreated Не могли бы вы установить Naginator + Plugin # 2967, как уже много раз обсуждалось? (Пожалуйста, сделайте снимок перед внесением изменений в Jenkins.)

hetzner-jenkins1 : превышена дисковая квота

@Mistreated Не могли бы вы установить Naginator + Plugin # 2967, как уже много раз обсуждалось? (Пожалуйста, сделайте снимок перед внесением изменений в Jenkins.)

Сделаю это сегодня

hetzner-jenkins1: превышена дисковая квота

@mpranj Я добавил новый VM в качестве агента сборки, пока hetzner-jenkins1 не работает.

Я очистил место на hetzner-jenkins1, запустив docker system prune -a и снова включив его.

Похоже, снова возникает проблема, заключающаяся в том, что многие вещи не очищаются с помощью docker system prune -f . На этот раз драйвером хранилища был не btrfs а vfs . :смущенный:

Я добавил новую виртуальную машину в качестве агента сборки, пока hetzner-jenkins1 не работает.

Идея сейчас в том, что мы больше не используем контейнер, а вместо этого используем только виртуальную машину.

Я очистил место на hetzner-jenkins1, запустив docker system prune -a и снова включив его.

Большое спасибо! Можно еще там cronjob сделать? (на виртуальной машине, а не на контейнере).

сделать там cronjob?

Выполнено.

@Mistreated Не могли бы вы установить Naginator + Plugin # 2967, как уже много раз обсуждалось? (Пожалуйста, сделайте снимок перед внесением изменений в Jenkins.)

Мы должны перейти от пайплайна к фристайлу, если нам нужен плагин naginator. Я буду искать альтернативы.

Сборки на виртуальной машине jenkinsNode3VM настоящее время не выполняются. Они не могут вытягивать докеры:

unexpected EOF
script returned exit code 1

Я отключил его, пока кто-нибудь не исправит проблему.

[cronjob] Готово.

Спасибо!

Мы должны перейти от пайплайна к фристайлу, если нам нужен плагин naginator. Я буду искать альтернативы.

Да, хорошая идея. Может быть, лучше просто закодировать это в нашем Jenkinsfile. Поэтому, если проблемное задание / этап сборки не удается, выполняется повторная попытка. Эти подтягивания докеров повторяются как минимум дважды, поскольку это одна из наиболее частых проблем.

Сборки на виртуальной машине jenkinsNode3VM в настоящее время не работают. Они не могут вытягивать докеры:

@Mistreated, пожалуйста, исправьте это.

Сборки на виртуальной машине jenkinsNode3VM в настоящее время не работают. Они не могут тянуть докер

Исправил образ докера, который нельзя было вытащить.

Большое спасибо! Всегда полезно написать, что было не так и как вы это исправили.

Понятия не имею, в чем дело, я создал образ вручную на агенте. Поскольку агент не смог его вытащить.

Что касается Dockerfile, (scripts/docker/debian/stretch) my Visual Code говорит, что у него две пустые строки на конце, но vim говорит, что это только одна. Я не знаю, должно ли это что-то делать с ошибкой выше, может быть, это просто мой VS .

Похоже, у нас проблемы с реестром докеров (# 3316 docker pull не работает с unexpected EOF ).

Поскольку пыль после выпуска улеглась и сборок не ведется, я бы посоветовал остановить все и попытаться полностью очистить реестр. После этого все изображения должны быть восстановлены, надеюсь, чисто. Я бы сделал резервную копию данных реестра, прежде чем начать, просто чтобы убедиться, но я надеюсь, что чистый запуск избавит от некоторых ошибок, которые у нас были.

Я подожду комментариев, есть ли что-нибудь против, прежде чем начну.

Я думаю, проблема в

(скрипты / докер / дебиан / растяжка)

изображение, так как это единственный сбой.

Я снова собрал его вручную, но с изображением в реестре определенно что-то не так.

Отчеты Jenkins: jenkinsNode3VM (офлайн)

@Mistreated было бы здорово, если бы вы могли настроить какой-либо способ мониторинга.

a7 (и, следовательно, v2 и i7 ) не работают. Связался с админом.

ИЗМЕНИТЬ markus2330: снова вверх

Из-за запланированного отключения электроэнергии на 08.07.2020 в TU Wien наш администратор планирует отключить все серверы сборки накануне (вторник, 7.7). Сборка будет очень медленной в это время, поэтому, пожалуйста, нажимайте в этот день только в экстренных случаях.

Серверы снова в сети, кроме i7. Я уведомил админа.

Вчера вечером произошло еще одно отключение электроэнергии (незапланированное), поэтому все серверы сборки сейчас не работают. Админ над этим работает.

РЕДАКТИРОВАТЬ 30 минут спустя: все, включая i7, снова работает: rocket:

@ markus2330 похоже, что v2 и i7 недавно потеряли доступ в Интернет (возможно, во время отключения электроэнергии?). Известно ли вам о каких-либо изменениях конфигурации, которые мы должны были внести, поскольку интерфейсы настроены статически?

Я не знаю ни о каких изменениях, только о том, что компьютеры снова были включены после этих двух отключений электроэнергии (одного планового, другого незапланированного).

Но вы правы, я также вижу, что у них этих двоих (но не а7) больше нет выхода в интернет, хотя они доступны. Я спросил об этом нашего админа.

Может быть, мы отключим их от Jenkins, пока эта проблема не будет исправлена?

Спасибо, что обратились к админу! Я отключил i7 и v2, пока проблема не исчезла. (Сборки все равно не работают, потому что они не могут извлекать образы докеров)

Кто-то что-то поменял с роутером неделю назад. Человек был уведомлен и, надеюсь, скоро исправит это.

Давайте пока оставим их отключенными.

Проблема с Интернетом теперь решена, и я также установил обновления безопасности на эти машины.

@mpranj, не могли бы вы снова включить их?

Спасибо @ markus2330.

Все узлы снова подключены к сети.

Я перезагрузил сервер сборки для последней версии ядра PVE. Дженкинс должен скоро встать.

я переехал

• [] сделать отправку писем в случае сбоя сборки более надежной
• [] Образ Docker без пользователя Jenkins
• [] образы докеров CentOS / Fedora / Arch
• [] пакеты CentOS
• [] агенты сборки freebsd / openbsd / solaris

на # 3519 и связанный с # 3519 выше.

@robaerd теперь также имеет доступ к a7 / v2 / i7 и может связаться с админом в случае проблем.

Просто краткий отчет о времени сборки (основной конвейер libelektra ):

• с включенным a7 : 2h 29m 24s
• с отключенным a7 : 1h 35m 45s

Почему Дженкинс показывает, что он отключается? Хорошо бы всегда читать здесь заранее: wink:

Jenkins будет отключен из-за полного резервного копирования системы и переформатирования файловых систем с btrfs на ext4.

Дженкинс снова встал

Jenkins CI будет отключен на техническое обслуживание примерно с 11:15 по центральноевропейскому времени сегодня.

Мы выполним несколько задач резервного копирования и очистки и попытаемся повысить производительность a7 .

Вы получите уведомление снова, когда техническое обслуживание закончится.

Jenkins CI и все серверы сборки снова включены. a7 теперь должен работать намного лучше, но имеет меньшую емкость хранилища.

Сообщите, если у вас возникнут какие-либо ошибки.

Jenkins CI и агенты сборки будут отключены на короткое время обслуживания / обновлений.

РЕДАКТИРОВАТЬ: обновления сделаны.

Сервер не работает, я исследую.

Сервер снова работает.

Официальное заявление о причине: «Возникла проблема с блоком питания на соседнем сервере, из-за которой сервер отключился; теперь она исправлена».

SSD в a7 заполнен, что приводит к сбою всех его сборок.

Я постараюсь освободить место. Безопасно ли сейчас отключать агент сборки a7 от jenkins?

Спасибо, что изучили это!

Я постараюсь освободить место. Безопасно ли сейчас отключать агент сборки a7 от jenkins?

Конечно. Напротив, было бы небезопасно держать его подключенным, если это приведет к сбою всех сборок.

Запуск docker system prune -a снова очистил примерно 50% пространства. Может быть, нам нужно адаптировать существующее задание cron, чтобы добавить флаг -a ?

В доме Дженкинсов тоже много места.

Основные сборки (полный конвейер с пакетами deb и создание веб-сайта) почему-то все еще не работают, хотя все выглядит зеленым. Любые идеи?

Загрузка основных пакетов deb в community не выполняется в файле elektra_0.9.3.orig.tar.gz . Вероятно, это проблема с правами доступа к файлу. Сейчас я удалю его из каталога и позволю воссоздать его при следующем запуске.

Каким-то образом sshPublisher, если он терпит неудачу, не ставит сцену на красный.

Может быть, нам нужно адаптировать существующее задание cron, чтобы добавить флаг -a?

Была ли какая-то причина, по которой вы этого не сделали? Если нет, звучит как хорошая идея.

Jenkins CI и реестр на a7 будут отключены для миграции образа сторожевой башни в новую версию. Это займет всего пару минут.

РЕДАКТИРОВАТЬ: обновления выполнены, и Jenkins CI снова работает

Дженкинс и агенты ненадолго отключатся для получения обновлений.

РЕДАКТИРОВАТЬ: все было обновлено и снова работает. Мне нужно было исправить проблему, когда a7 использовал пакеты докеров Debian stretch вместо buster. Я также прибрал немного места.

Сборка не выполняется, так как на a7 .

Инфраструктура сборки будет недоступна в течение нескольких минут для обслуживания.

Инфраструктура сборки снова доступна.