Почему не стоит привязываться к номеру Build в проектах развёртывания Bamboo

Что это было? (С) Генерал

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

При работе с проектами развёртывания в Bamboo увидел интересную ситуацию (см. скриншот ниже).

В формировании версии использовался номер сборки.  

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

Разница составила всего ничего, а суда по всему в проекте развёртывания, Bamboo признал последней версию с номером 189, хотя реально 190-я была последней с точки зрения изменения кода. Наверное, это не страшно, т.к. в моём случае номер сборки не являлся определяющим, но хотелось бы, чтобы нумерация шла по порядку.

Проблема с загрузкой артифактов на Bamboo CI Server

В процессе работы столкнулся с проблемой при загрузке артифактов на сервер Bamboo.

Характерная ошибка, возникающая в логах плана, выглядит следующим образом:

26-Mar-2020 17:49:10 com.atlassian.bamboo.build.artifact.BambooRemoteArtifactHandler: java.net.SocketException: Software caused connection abort: socket write error
26-Mar-2020 17:49:10 Unable to publish artifact [All source code]: Unable to publish artifact Required job artifact: [All source code], pattern: [**] for KDP-WDIBD11-BA-1 via com.atlassian.bamboo.build.artifact.BambooRemoteArtifactHandler@5ad7c7
26-Mar-2020 17:49:10 The artifact is required, build will now fail.


Во всех случаях и с IIS, и с Tomcat проблемы вызывается двумя факторами: 

• либо это таймаут на загрузку;
• либо ограничение размера на загрузку контента;

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

Проблема с JavaSpec и Docker в Bamboo 6.10.4, установленном на Windows Server

Пытался написать план на основе JavaSpec и для того, чтобы Bamboo смог использовать его - создал необходимый репозитарий. Настроил соотвествующие Checkbox и в предвкушении нажал кнопку Scan.

Заметка: не забудьте установить Docker на хосте с  Bamboo CI Server. Также, понадобиться настроить Docker для запуска Linux контейнера на Windows.

Bamboo пошуршал и выдал ошибку.

Необходимо убедиться, что сервис Bamboo  работает из под доменной/локальной учётной записи, но не из под системной, иначе получите следующую ошибку.

1:30 Caused by: com.spotify.docker.client.exceptions.DockerException: java.util.concurrent.ExecutionException: com.spotify.docker.client.shaded.javax.ws.rs.ProcessingException: com.spotify.docker.client.shaded.org.apache.http.conn.HttpHostConnectException: Connect to localhost:2375 [localhost/127.0.0.1, localhost/0:0:0:0:0:0:0:1] failed: Connection refused: connect

Однако, после исправления проблему с учётной записью и перезапуска Scan стало веселее:

01-Apr-2020 15:58:27 Unable to scan repository Verification Bamboo Specs (18415878) for Bamboo Specs
01-Apr-2020 15:58:27 com.atlassian.bamboo.repository.RepositoryException: Unable to scan repository Verification Bamboo Specs (18415878) for Bamboo Specs
01-Apr-2020 15:58:27 at com.atlassian.bamboo.configuration.external.RepositoryStoredSpecsServiceImpl.lambda$runSpecsWithDocker$9(RepositoryStoredSpecsServiceImpl.java:935)
01-Apr-2020 15:58:27 at java.util.concurrent.FutureTask.run(Unknown Source)
01-Apr-2020 15:58:27 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
01-Apr-2020 15:58:27 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
01-Apr-2020 15:58:27 at com.atlassian.bamboo.utils.BambooRunnables$1.run(BambooRunnables.java:48)
01-Apr-2020 15:58:27 at com.atlassian.bamboo.security.ImpersonationHelper.runWith(ImpersonationHelper.java:26)
01-Apr-2020 15:58:27 at com.atlassian.bamboo.security.ImpersonationHelper.runWithSystemAuthority(ImpersonationHelper.java:17)
01-Apr-2020 15:58:27 at com.atlassian.bamboo.security.ImpersonationHelper$1.run(ImpersonationHelper.java:41)
01-Apr-2020 15:58:27 at java.lang.Thread.run(Unknown Source)
01-Apr-2020 15:58:27 Caused by: com.spotify.docker.client.exceptions.DockerRequestException: Request error: POST https://192.168.99.100:2376/containers/create?name=bamboo-specs-6900b8d8-551c-4d96-ba8b-ef2530d5c8e6: 400, body:

{"message":"the working directory '\\mnt\\input' is invalid, it needs to be an absolute path"}

01-Apr-2020 15:58:27

И вот тут крылось удивительное: в Bamboo существует баг, который приводит к ошибке выше, если Bamboo CI Server установлен на Windows Server. Судя по всему этот баг никто пока не исправил и не понятно когда исправят. 

"BambooBAM-20115RSS processing inside Windows Docker Engine container uses incorrect path representation"

В общем, рекомендация одна - используйте Linux.

Как Bamboo хранит артифакты

Все артифакты хранятся в папке Artifacts внутри bamboo-home. Агенты не участвуют в долговременном хранении артифактов.

Важно! Необходимо понимать, что любые сгенерированные артифакты в виде zip архивов, nuget пакетов и т.д. будут продолжать находиться в рабочей папке работы плана на агенте до момента удаления этой папки. Но в тоже время, Deployment проекты будут потреблять не их, а артифакты с CI сервер.

То есть, все артифакты, сгенерированные в процессе запуска Build на удалённом агенте, будут переданы на сервер CI.








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

Учитывайте это при планировании и не забывайте пользоваться возможность настроить "Expire" (см. предыдущий пост).

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

Закончилось место на агенте Bamboo?

К сожалению, нет встроенного механизма удаления результатов запуска плана на удалённых агентах Bamboo даже в версии 6.10.4. Мы можем вычистить только дисковое пространство на сервере CI с помощью нескольких настроек "Expiry". Также, есть возможность переопределись некоторые значения на уровне плана.

Однако, когда Ваш CI сервер выполняет большое кол-во работы дисковое может закончиться очень быстро.

Чтобы решить эту проблему можно воспользоваться простым скриптом, приведённым ниже, раскидав его с помощью GPO или иным способом в Task Scheduler.

$folder = "C:\bamboo\xml-data\build-dir"

$EndDate= Get-date

$itemsListArray = Get-ChildItem -Path $folder -Exclude _git-repositories-cache,repositoryData

foreach($item in $itemsListArray){

    $startDate = [datetime]$item.LastWriteTime

    $result = New-TimeSpan -Start $startDate -End $EndDate

    

    if($result.Days -ge 21)

        {

            $pathToRemove =  $folder + '\' + $item.Name

            Remove-item -Path $pathToRemove -Recurse -Force  -Verbose

        }

}    

Данный скрипт удалит все папки старше 3-х недель.

ВАЖНО! Я рекомендую не использовать диск "С" для размещения данных Bamboo Server / agent - это может создать высокую нагрузку на диск и привести к проблемам с ОС, также возможны отказы при исчерпании дискового пространства.

"NPM CI" приводит к ошибке при использовании его в задаче "NPM configuratuion" Bamboo CI Server

Not all updates are equally helpful

После обновления Node.JS и NPM до версии 6.13.4 столкнулся с серией проблем (часть описанна ранее).

Одна из этих проблем связана с ключом NPM CI - перестал работать "NPM configuration" task из плана на Bamboo CI server. 

Сыпятся различные неинформативные ошибки.

Как итог обнаружилось несколько открытых багов, обсуждение одного из которых привело https://github.com/npm/cli/issues/558#issuecomment-580392554.

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

Node.JS 12.16.1 падает при попытке остановить компоненты зависимостей Visual Studio 2017

What ever weird is happening  - 

Keep calm and keep updating

Ничего нового - просто обновитель хотя бы до

OS Name: Microsoft Windows 10 Pro

OS Version: 10.0.18363 N/A Build 18363

И всё заработает как ожидалось.

Установка Node.JS 12.16.1 LTS падает с ошибкой установки зависимостей

What ever weird is happening  - 

Keep calm and keep updating

При инсталляции Node.JS 12.16.1 LTS можно поставить галочку в мастере установки, которая должна установить необходимые зависимости, скачав их из Интернет. 

Однако, открывшееся окно PowerShell после начало установки вываливается с ошибкой:

Exception calling "DownloadString" with "1" argument(s): "The request was aborted: Could not create SSL/TLS secure

channel."

At line:1 char:51

+ ... ess -Force; iex ((New-Object System.Net.WebClient).DownloadString('ht ...

+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException

    + FullyQualifiedErrorId : WebException

Данная ситуация была обнаружена мной на нескольких агентах CI/CD, использующих PowerShell:

Current $PSVersionTable:

Name Value

---- -----

PSVersion 5.1.17134.407

PSEdition Desktop

PSCompatibleVersions

{1.0, 2.0, 3.0, 4.0...}

BuildVersion 10.0.17134.407

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

Причина возникновения данной ошибки в том, что, по умолчанию, до определённой версии Windows Server/PowerShell поддерживалась толко TLS 1.0 - 1.1 или сервер имеет какие-либо ограничения, позволяющие использовать только TLS 1.1+.

Сначала я применил решение, описанное на сайте Choco.

В файле C:\Program Files\nodejs\install_tools.bat я добавил часть, выделенную жирным:

"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command Start-Process '%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe' -ArgumentList '-NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "[System.Net.ServicePointManager]::SecurityProtocol = 3072; iex ((New-Object System.Net.WebClient).DownloadString(''https://chocolatey.org/install.ps1''))"; choco upgrade -y python2 visualstudio2017-workload-vctools; Read-Host ''Type ENTER to exit'' ' -Verb RunAs

Но поразмыслив, я решил обновить один из агентов до более свежей версии Windows 10/PowerShell и о чудо: проблема решилась сама собой.

Для PowerShell версии, указанной ниже, проблемы не существует:

Name Value

---- -----

PSVersion 5.1.17763.1007

PSEdition Desktop

PSCompatibleVersions

{1.0, 2.0, 3.0, 4.0...}

BuildVersion 10.0.17763.1007

CLRVersion 4.0.30319.42000

WSManStackVersion 3.0

PSRemotingProtocolVersion 2.3

SerializationVersion 1.1.0.1

Back again

Time to write...

Наконец-то я добрался до блога. 

За этот год произошли кое-какие изменения в моей работе и теперь часть статей будет посвящено страшным словам DevOps, CI/CD, etc.

Тем не менее, я продолжаю оставаться Microsoft-ориентированным человеком :) , т.к. попытка спрыгнуть на Open Source так и не началась.

Мир ИТ меняется. Меняются подходы и как следствие рынок позиций, доступных ИТ специалистам.