GitLab Variable Migration
Budget: ₹600 – ₹1,500 INR
I need help cleaning up our GitLab pipelines. Right now we launch new pipelines through the “Run pipeline” screen and fill in several runtime variables every time. I only want a selected subset of those variables to live there; the rest should sit permanently in the project-level CI/CD settings so the pipeline can trigger hands-free.
Here’s what I’d like you to do:
• Audit the existing runtime variables shown on the new-pipeline page and confirm with me which ones must stay interactive and which can be fixed in the settings.
• Add the agreed-upon variables to Settings → CI/CD → Variables, choosing the right scope (environment-specific or protected as required).
• Refactor .gitlab-ci.yml so it reads the new variables correctly and no longer prompts for them when the pipeline is started.
• Prove the migration works by running a test pipeline that passes all stages without manual input for the moved variables.
• Remove any obsolete or duplicate variables you find and briefly document the final set for future reference.
Tooling is straight GitLab; no external runners or exotic extensions—just solid YAML, variable scoping, and best-practice DevOps hygiene.
If you’ve handled similar variable reorganisations before, this should be a quick, well-defined task.
Here’s what I’d like you to do:
• Audit the existing runtime variables shown on the new-pipeline page and confirm with me which ones must stay interactive and which can be fixed in the settings.
• Add the agreed-upon variables to Settings → CI/CD → Variables, choosing the right scope (environment-specific or protected as required).
• Refactor .gitlab-ci.yml so it reads the new variables correctly and no longer prompts for them when the pipeline is started.
• Prove the migration works by running a test pipeline that passes all stages without manual input for the moved variables.
• Remove any obsolete or duplicate variables you find and briefly document the final set for future reference.
Tooling is straight GitLab; no external runners or exotic extensions—just solid YAML, variable scoping, and best-practice DevOps hygiene.
If you’ve handled similar variable reorganisations before, this should be a quick, well-defined task.