improvements to deps-project-tool.py (release tool) (!5568) · Merge requests · Sylva-projects / sylva-core

This MR reflects the changes brought to deps-project-tool.py in the context of branching for Sylva 1.5 to handle "wrong tags".

Wrong tags

After creating a release-x.y in sylva-core, we may have some sylva-element repo Y in the following situation:

sylva-core release-x.y branch uses tag U.V.W, which is now the tip release-U.V branch
U.V.W tags where made in repo Y before that, which hadn't been used in sylva-core yet
each such U.V.(W+n) although named U.V.* is not on release-U.V branch and not meant to be used for Sylva release-x.y
this will create confusion and mess, and will break Renovate Bot behavior (renovate would propose updates on release-x.y using such tags)
we call such tags "wrong tags"

Before this MR, tools/deps-project-tool.py was already able to detect such problems

What we did in past release was to manually fix the situation:

(DO NOT delete the wrong u.v.(w+1) tag: deleting Git tags is most often something we regret, people having clones will by default not see the tag deletion, the tag might later be recreated on another commit, etc.)
what we do in such a case is, assuming the highest "wrong tag" is U.V.Wn
create a U.V.(Wn+1) tag on the same commit as U.V.W (the tag currently used by sylva-core release-x.y)
- U.V.(Wn+1) is called the "fixing tag"
update sylva-core release-x.y branch to use U.V.(Wn+1)
- Renovate Bot MRs for release-x.y will naturally use this tag, they simply need to be merged (this is trivial since no code change is involved)
also create a U.(V+1).1 tag on the same commit as the highest "wrong tag"
- the renovate bot MRs for main that were, before the fork, pointing to U.V.Wn will now be updated to point to U.(V+1).1 because its the most recent
- this is all good, because it's the same commit as U.V.Wn
- (U.(V+1).1 is called the "fixing tag for next release")

With this MR, tools/deps-project-tool.py is now able to apply this remediation

Additionally, it will also retitle any existing Gitlab Release for any "wrong tag", giving it a new title saying "withdrawn, use <U.V.Wn> instead" and emptying its release notes.

Here is example output (the run which actually fixed the repos after branching release-1.5).

Other changes

minor output changes
some minor refactoring
f-string compatibility with Python 3.12
improved some error management

CI configuration

Below you can choose test deployment variants to run in this MR's CI.

Click to open to CI configuration

Legend:

Icon	Meaning	Available values
☁️	Infra Provider	`capd`, `capo`, `capm3`
🚀	Bootstrap Provider	`kubeadm` (alias `kadm`), `rke2`, `okd`, `ck8s`
🐧	Node OS	`ubuntu`, `suse`, `na`, `leapmicro`
🛠️	Deployment Options	`light-deploy`, `dev-sources`, `ha`, `misc`, `maxsurge-0`, `logging`, `no-logging`, `openbao`
🎬	Pipeline Scenarios	Available scenario list and description

Global config for deployment pipelines

autorun pipelines
allow failure on pipelines
record sylvactl events

Notes:

Enabling autorun will make deployment pipelines to be run automatically without human interaction
Disabling allow failure will make deployment pipelines mandatory for pipeline success.
if both autorun and allow failure are disabled, deployment pipelines will need manual triggering but will be blocking the pipeline

Be aware: after configuration change, pipeline is not triggered automatically. Please run it manually (by clicking the run pipeline button in Pipelines tab) or push new code.

Edited Sep 24, 2025 by Thomas Morin

improvements to deps-project-tool.py (release tool)

Wrong tags

Other changes

CI configuration

Global config for deployment pipelines

Merge request reports