Fix backup id parsing from backup URLs
What does this MR do?
Fix backup id parsing from backup URLs
The backup id is parsed from the backup URL to be passed to the rake restore processes.
This parsing currently fails with:
/usr/local/bin/backup-utility: line 322: <backup_id>%_gitlab_backup.tar: command not found
This is unproblematic when a backup id is specified, but causes missing repository restores when a full backup URL was specified.
Changelog: fixed
Related issues
Related MR: !1604 (merged)
Relates gitlab-org/charts/gitlab#5074 (closed)
Checklist
See Definition of done.
For anything in this list which will not be completed, please provide a reason in the MR discussion
Required
-
Merge Request Title, and Description are up to date, accurate, and descriptive -
MR targeting the appropriate branch -
MR has a green pipeline on GitLab.com -
When ready for review, MR is labeled "~workflow::ready for review" per the Distribution MR workflow
Expected (please provide an explanation if not completing)
-
Test plan indicating conditions for success has been posted and passes -
Confirm backup ids are parsed as expected: # BACKUP_TIMESTAMP=1701850015_2023_12_06_16.7.0-pre BACKUP_URL=file:///tmp/1701850015_2023_12_06_16.7.0-pre_gitlab_backup.tar backup_remote=${BACKUP_URL:-$BACKUP_TIMESTAMP} backup_basename=$(basename "$backup_remote") backup_id=${backup_basename%_gitlab_backup.tar} echo "remote: ${backup_remote}; basename: ${backup_basename}; id: ${backup_id}"
-
-
Documentation created/updated -
Integration tests added to GitLab QA -
The impact any change in container size has should be evaluated -
New dependencies are managed with dependencies.io
Edited by Clemens Beck