Fix include/includeAll to correct track relativeToChangelog=true paths using ./ or ../

[nvoxland]

Impact

• Bug fix (non-breaking change which fixes expected existing functionality)
• Enhancement/New feature (adds functionality without impacting existing logic)
• Breaking change (fix or feature that would cause existing functionality to change)

Description

Changes in 4.17.0 made a changelog like <include file="./changelog.workspace.sql" relativeToChangelogFile="true"/> incorrectly include the ./ in the databasechangelog table and status --verbose among other places.

The correct fix is in the Resource's resolveSibling() function, but this is a temporary work around until we have a better solution in there.

Things to be aware of

• Only impacts included changesets

Things to worry about

• Nothing

[github-actions]

Unit Test Results

  4 740 files  ±  0    4 740 suites  ±0   37m 12s ⏱️ + 3m 3s
  4 693 tests  - 18    4 457 ✔️  - 21     236 💤 +3  0 ❌ ±0 
55 536 runs   - 12  50 228 ✔️  - 17  5 308 💤 +5  0 ❌ ±0 

Results for commit bd5a3ea. ± Comparison against base commit 665a311.

♻️ This comment has been updated with latest results.

[borjapenman]

Using ../ when relativeToChangelog=true seems quite common use case. Is thsis going to be merged for the next release?

[filipelautert]

Fixed tests, so there is test coverage.

[XDelphiGrl]

PR addresses a regression in the path shown some output messages and the value stored in DATABASECHANGELOG tracking table when include or includeAll changesets specify relativeToChangelog=true.

• Automated functional and test harness executions passing.
• New unit test added.
• No additional testing required.

APPROVED

[SamD]

This impacts existing migrations so this is a breaking change wouldn't it be ?

On migration , for a sql file, the filename will include the path separator in the changelog table
With this update that name no longer matches on a deployment so the existing migration attempts to run again
checksums are equal , names are different

[filipelautert]

This impacts existing migrations so this is a breaking change wouldn't it be ?

On migration , for a sql file, the filename will include the path separator in the changelog table With this update that name no longer matches on a deployment so the existing migration attempts to run again checksums are equal , names are different

Well, it went back to as it was before 4.17.0 . So if you already faced this problem with 4.17 you need to run clearChecksums before upgrading.