Summary
.vortex/tests/update-test-assets fetches the mariadb-drupal-data seed script from a GitHub releases/latest/download URL and executes it. The script that builds the demo and test database images is therefore whatever the newest upstream release contains at the moment the command runs, with no record of which version produced a given database image.
Details
.vortex/tests/update-test-assets line 43:
const SEED_URL = 'https://github.com/drevops/mariadb-drupal-data/releases/latest/download/seed.sh';
The seeding path is already sensitive to upstream behaviour changes: the platform defaults in mariadb-drupal-data changed to host-only, which is why the script now has to set DESTINATION_PLATFORMS and use a dedicated buildx builder. That fix was needed precisely because an upstream change arrived without a version bump on this side to review it against.
Fetching a script over the network and executing it also means the pin question is a supply-chain question, not only a reproducibility one.
Suggested resolution
Pin the URL to an explicit mariadb-drupal-data release tag, so the seeding behaviour changes only when someone bumps it deliberately. Renovate's github-releases datasource can track the tag in the URL through a customManagers regex, so the pin surfaces as a reviewable PR rather than rotting.
Verifying a checksum for the downloaded script is worth considering alongside the pin.
Related
Found while auditing for unpinned tool versions after the hadolint incident in #2868. The untagged alpine image in the same file is tracked separately.
Summary
.vortex/tests/update-test-assetsfetches themariadb-drupal-dataseed script from a GitHubreleases/latest/downloadURL and executes it. The script that builds the demo and test database images is therefore whatever the newest upstream release contains at the moment the command runs, with no record of which version produced a given database image.Details
.vortex/tests/update-test-assetsline 43:The seeding path is already sensitive to upstream behaviour changes: the platform defaults in
mariadb-drupal-datachanged to host-only, which is why the script now has to setDESTINATION_PLATFORMSand use a dedicated buildx builder. That fix was needed precisely because an upstream change arrived without a version bump on this side to review it against.Fetching a script over the network and executing it also means the pin question is a supply-chain question, not only a reproducibility one.
Suggested resolution
Pin the URL to an explicit
mariadb-drupal-datarelease tag, so the seeding behaviour changes only when someone bumps it deliberately. Renovate'sgithub-releasesdatasource can track the tag in the URL through acustomManagersregex, so the pin surfaces as a reviewable PR rather than rotting.Verifying a checksum for the downloaded script is worth considering alongside the pin.
Related
Found while auditing for unpinned tool versions after the
hadolintincident in #2868. The untaggedalpineimage in the same file is tracked separately.