Fix: Архивировать результирующие файлы 1Cv8.1CD только используемые

[Kyrales]

Архивировать результирующие файлы 1Cv8.1CD только, в случае если это была инициализация базы или возникла необходимость отмеченная в опции с помещением в stash.

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

[coderabbitai]

Walkthrough

В ZipInfobase.run() добавлено условие: операции zip и stash выполняются только при stage == 'initInfoBase' или если archiveInfobase == true. Логика формирования имени архива сохранена: для initInfoBase — "1Cv8.1CD.zip", иначе — "1Cv8.1CD.{stage}.zip". Объявления публичных сущностей не менялись.

Changes

Cohort / File(s)	Summary
Условное архивирование инфобазы src/ru/pulsar/jenkins/library/steps/ZipInfobase.groovy	Добавлено ветвление: zip/stash выполняются только для stage 'initInfoBase' или при установленном флаге archiveInfobase; удаление старого архива и схема именования без изменений.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    actor Jenkins as Jenkins Pipeline
    participant Zip as ZipInfobase.run
    participant FS as FS
    participant Stash as Jenkins Stash

    Jenkins->>Zip: run(stage, archiveInfobase)
    Zip->>FS: delete existing archive (если есть)
    alt stage == "initInfoBase"
        Zip->>FS: zip 1Cv8.1CD -> 1Cv8.1CD.zip
        Zip->>Stash: stash archive
    else archiveInfobase == true
        Zip->>FS: zip 1Cv8.1CD -> 1Cv8.1CD.{stage}.zip
        Zip->>Stash: stash archive
    else
        Note over Zip: Пропуск zip/stash
    end

Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Сохранение ИБ в виде артефакта после выполнения всех шагов инциализации #149 — Ранние изменения логики архивирования в ZipInfobase; текущий PR корректирует выполнение zip/stash в том же месте.

Suggested reviewers

• nixel2007

Poem

В норе CI шуршит архивный скрипт,
Ступень проверит — и пакет летит.
Init — в мешок! И stash в пути,
А прочим — лапкой: «Погоди».
Пушистый билд даёт отбой —
Условный зайчик — наш герой. 🐇📦

✨ Finishing Touches

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

src/ru/pulsar/jenkins/library/steps/ZipInfobase.groovy (1)

37-44: Комментарий про область действия опции вводит в заблуждение.

Сейчас флаг далее влияет не только на “сохранение артефакта”, но и на сам факт выполнения zip/stash (кроме initInfoBase). Уточните комментарий, чтобы будущие изменения не поломали поведение по недопониманию.

-        // опция отвечает только за то, будет ли файл сохранен в виде артефакта
+        // Внимание: вычисленный ниже флаг управляет сохранением как артефакта
+        // и одновременно служит триггером выполнения zip/stash (кроме initInfoBase)

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 169082f and ccf7db5.

📒 Files selected for processing (1)

• src/ru/pulsar/jenkins/library/steps/ZipInfobase.groovy (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)

• GitHub Check: build

🔇 Additional comments (1)

src/ru/pulsar/jenkins/library/steps/ZipInfobase.groovy (1)

49-53: Добавить логирование и разделить флаги архивирования и stash.
Вынести условие в shouldZipAndStash, логировать текущее stage и archiveInfobase и, при необходимости, ввести отдельный флаг для stash, чтобы избежать нежелательного stash вне initInfoBase.

[nixel2007]

Не понимаю, откуда архивирование всего подряд? Основная функциональность этого шага - помещать базу в стэш. вызывается он только из тех мест, где нужно базу потом доставать из стэша. необходимость дополнительного прикладывания зипа как архив тоже вычисляется внутри самого шага.

[Kyrales]

Не понимаю, откуда архивирование всего подряд? Основная функциональность этого шага - помещать базу в стэш. вызывается он только из тех мест, где нужно базу потом доставать из стэша. необходимость дополнительного прикладывания зипа как архив тоже вычисляется внутри самого шага.

@nixel2007 например вариант, если без моего исправления по BDD проверке:
Отработало BDD тестирование успешно и указателя по опциям, что надо в артефакты закидывать архивы базы нет (archiveInfobase=false). Но по коду мы все равно зачем то архивируем просто так базу (лишнее время).

В моем коде это исправлено:
Архивируем по условию: если это ситуация с инициализацией базы или archiveInfobase=true .

[nixel2007]

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

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

я согласен с необходимостью доработки, но предлагаю чуть развернуть управление - пускай pipeline1C решает, нужно ли добавлять базу в стэш. что-нибудь типа доп параметра doStash. когда он передан как true (из ветки инициализации базы), тогда база добавляется в стэш в любом случае, а в артефакты - по текущей логике с определением currentResult и настроек. если флаг передан как false, то в стэш оно не кладется.
таким образом необходимость вызова steps.zip() управляется через archiveInfobase || stash, а steps.stash() - только по stash.

Как тебе идея?

[Segate-ekb]

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

Зато в итоге можно будет сделать сохранение не только дт, но и cf, cfe например

[Kyrales]

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

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

я согласен с необходимостью доработки, но предлагаю чуть развернуть управление - пускай pipeline1C решает, нужно ли добавлять базу в стэш. что-нибудь типа доп параметра doStash. когда он передан как true (из ветки инициализации базы), тогда база добавляется в стэш в любом случае, а в артефакты - по текущей логике с определением currentResult и настроек. если флаг передан как false, то в стэш оно не кладется. таким образом необходимость вызова steps.zip() управляется через archiveInfobase || stash, а steps.stash() - только по stash.

Как тебе идея?

@nixel2007 не сильно ли большое усложнение? Сейчас корректировка минимальна и решает конкретную задачу. Мне кажется в артефактах дженкинса база врятли вообще кому нить понадобится и плюс размер Дженкинса как правило не большой резервируется на виртуальных серверах.

[nixel2007]

Мне кажется в артефактах дженкинса база врятли вообще кому нить понадобится

Я регулярно доставал базу из артефактов на анализ падения тестов на VA. При наличии ЖР в аллюре - это удобный инструмент получался

[nixel2007]

@coderabbitai посмотри работу vars/pipeline1c.groovy и подчиненных файлов. распиши все варианты, в которых информационная база будет или не будет:

• архивирована
• помещена в архтефакты

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
echo "=== vars/pipeline1C.groovy ==="
cat vars/pipeline1C.groovy 2>/dev/null || echo "NOT FOUND"

echo ""
echo "=== ZipInfobase.groovy ==="
fd -i "ZipInfobase.groovy" --exec cat {}

echo ""
echo "=== All calls to zipInfobase or ZipInfobase ==="
rg -n "zipInfobase\|ZipInfobase" --type groovy -C 5

echo ""
echo "=== archiveInfobase references ==="
rg -n "archiveInfobase" --type groovy -C 3

echo ""
echo "=== stash references in pipeline files ==="
rg -n "\.stash\|steps\.stash\|stash(" --type groovy -C 3

echo ""
echo "=== initInfoBase references ==="
rg -n "initInfoBase\|InitInfoBase" --type groovy -C 3

Length of output: 26607

---

🏁 Script executed:

#!/bin/bash
echo "=== ArchiveInfobaseOptions ==="
fd -i "ArchiveInfobaseOptions.groovy" --exec cat {}

echo ""
echo "=== steps.zip / IStepExecutor zip ==="
rg -n "def zip\|void zip\|zip(" --type groovy -C 3

echo ""
echo "=== stash references ==="
rg -n "stash" --type groovy -C 2

echo ""
echo "=== unzipInfobase ==="
fd -i "unzipInfobase.groovy" --exec cat {}

Length of output: 16524

---

🏁 Script executed:

#!/bin/bash
echo "=== StepExecutor.zip ==="
rg -n "def zip" --type groovy -C 10

echo ""
echo "=== IStepExecutor.zip ==="
rg -n "zip" src/ru/pulsar/jenkins/library/IStepExecutor.groovy -C 2

echo ""
echo "=== BDD stage - check for zipInfobase call context ==="
rg -n "zipInfobase" --type groovy -C 8

echo ""
echo "=== stageFlags ==="
fd -i "StageFlags.groovy" --exec cat {}

Length of output: 14619

---

@nixel2007, вот полный разбор всех сценариев для ИБ по коду текущей ветки PR (fix/not_use_archive_1CD):

---

Когда вызывается zipInfobase

zipInfobase вызывается в pipeline1C.groovy только в двух местах:

Место вызова	Параметр stage	Имя архива	Условие вызова
После «Инициализация ИБ» (Line 147)	'initInfoBase'	1Cv8.1CD.zip	Всегда, если needInfoBase() = true
После «BDD сценарии» (Line 246)	'bdd'	1Cv8.1CD.bdd.zip	Только если stageFlags.bdd = true

Для syntaxCheck, smoke, yaxunit — zipInfobase не вызывается вообще. Все эти этапы лишь делают unzipInfobase(), который забирает стэш 1Cv8.1CD.zip (от initInfoBase).

---

Логика внутри ZipInfobase.run() (PR-ветка)

// archiveInfobase = true, если выполняется хотя бы одно условие из настроек:
//   onAlways || (onFailure && FAILURE/ABORTED) || (onUnstable && UNSTABLE) || (onSuccess && SUCCESS)
// По умолчанию все флаги = false → archiveInfobase = false

if (stage == 'initInfoBase' || archiveInfobase) {
    steps.zip('build/ib', archiveName, '1Cv8.1CD', archiveInfobase)
    //  ↑ archive: archiveInfobase — определяет, попадёт ли файл в артефакты Jenkins
    steps.stash(archiveName, archiveName, false)
}

---

Все варианты поведения

Этап initInfoBase (stage = 'initInfoBase')

Условие stage == 'initInfoBase' — всегда true, поэтому:

	Результат
Zip-файл создаётся	✅ Всегда
Помещается в stash	✅ Всегда (1Cv8.1CD.zip) — это требуется для bdd/smoke/yaxunit/syntaxCheck
Помещается в артефакты	Зависит от initInfoBaseOptions.archiveInfobase:
→ все флаги false (по умолчанию)	❌ Не архивируется
→ onAlways = true	✅ Всегда
→ onSuccess = true	✅ Только при SUCCESS
→ onFailure = true	✅ Только при FAILURE / ABORTED
→ onUnstable = true	✅ Только при UNSTABLE

Этап bdd (stage = 'bdd')

Условие stage == 'initInfoBase' — false, управление полностью через archiveInfobase:

	Результат
Zip-файл создаётся	⚠️ Только если archiveInfobase = true
Помещается в stash	⚠️ Только если archiveInfobase = true (1Cv8.1CD.bdd.zip)
→ все флаги false (по умолчанию)	❌ Ни zip, ни stash не создаются
→ onAlways = true	✅ Zip + stash + артефакт всегда
→ onSuccess = true	✅ Только при SUCCESS
→ onFailure = true	✅ Только при FAILURE / ABORTED
→ onUnstable = true	✅ Только при UNSTABLE
Помещается в артефакты	Только если archiveInfobase = true (то же условие)

⚠️ Ключевое наблюдение: 1Cv8.1CD.bdd.zip ни в одном из последующих этапов пайплайна не используется (unzipInfobase всегда берёт только 1Cv8.1CD.zip). Т.е. стэш для bdd нужен исключительно для сохранения в артефакты — для ручного анализа падений. С текущим PR при archiveInfobase=false (дефолт) этот стэш не создаётся, что ломает возможность достать базу на анализ (как раз тот кейс, о котором говорил @nixel2007).

Этапы syntaxCheck, smoke, yaxunit

	Результат
Zip-файл создаётся	❌ zipInfobase не вызывается
Помещается в stash	❌ Не помещается
Помещается в артефакты	❌ Не помещается

---

Итог по проблеме

Предложение @nixel2007 с параметром doStash решает именно это расхождение: steps.zip() вызывается по условию archiveInfobase || doStash, а steps.stash() — только по doStash. Тогда для initInfoBase всегда передаётся doStash=true, а для bdd — тоже true (если нужна возможность анализа базы), при этом попадание в артефакты управляется отдельно через archiveInfobase.

---

🧠 Learnings used

Learnt from: CR
Repo: firstBitMarksistskaya/jenkins-lib PR: 0
File: .github/copilot-instructions.md:0-0
Timestamp: 2025-08-27T05:31:27.548Z
Learning: Applies to vars/pipeline1C.groovy : Review and update the main pipeline flow in vars/pipeline1C.groovy when modifying overall pipeline logic

---

Learnt from: nixel2007
Repo: firstBitMarksistskaya/jenkins-lib PR: 170
File: build.gradle.kts:29-32
Timestamp: 2025-08-26T19:41:49.802Z
Learning: В репозитории firstBitMarksistskaya/jenkins-lib используется sparse-checkout конфигурация, которая исключает .jar файлы (!**/*.jar). Это может привести к тому, что gradle-wrapper.jar отсутствует в рабочем дереве, даже если он существует в репозитории.

[Copilot]

Pull request overview

Оптимизация Jenkins shared library шага архивации ИБ 1C: zip/stash теперь выполняются только когда архив действительно нужен (для initInfoBase или при включенной опции архивации по результату), чтобы не тратить время на лишние операции.

Changes:

• Добавлено условие, ограничивающее выполнение zip()/stash() для не-initInfoBase этапов.
• Сохранено обязательное создание/stash архива для initInfoBase, чтобы последующие этапы могли распаковать ИБ.