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 не сильно ли большое усложнение? Сейчас корректировка минимальна и решает конкретную задачу. Мне кажется в артефактах дженкинса база врятли вообще кому нить понадобится и плюс размер Дженкинса как правило не большой резервируется на виртуальных серверах.