Feature summary (what you would like to be able to do and where):
Currently the source of the config is specified within the config.
Being able to specify the source configuration outside of the components (today that fails validation enforcing at least 1 component exists) would reduce the risk of accidentally deploying a config with the wrong source_url, breaking the new deployment (i.e. not immediately obvious).
Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
When storing component configurations in a external source of truth, such as a git repo, it is sometimes desirable to deploy alternate versions to different projects.
As an example, deploying the component config to staging and validating (from a branch) prior to deploying to production.
Today this isn't really possible as the source_url (next up source_repo) gets flipped to what is in the external file, from what was specified during create.
Benefits (why should this be implemented?):
This would enable more flexible usage of the components service by maintainers ex. T401868, T401388
This would reduce the likelihood of broken configurations due to the 'state' of the source being stored in 2 places
Example:
Default:
toolforge components config setup<<'EOF' source: null EOF
Allows:
toolforge components config create<<'EOF'
components:
pony:
build:
repository: https://very.special.pony
run:
command: i-am-a-unicorn
EOFWith source:
toolforge components config create<<'EOF' source: url: https://very.special.pony EOF
Refuses toolforge components config create, toolforge components config show causes refresh from remote (same as deploy)
This secondary structure would allow for further configuration that is not component related, for example perhaps how many builds to retain based on pattern.