Continuous integration and deployment pipelines are likely to have dependencies. For example, private docker repositories to push and pull intermediate or shared build stages. Another example would be the AWS cloud configuration to define an instance.
My goal is to avoid contaminating my code base with specifics about the dependencies specific to my development environment setup; allowing easier code portability.
Initially, I have had some success in using branch naming conventions to define deployment environments. For example, branches named ādeploy/AWS_REGION/APPNAMEā allow pipeline tasks to run on branches named ādeploy//ā, pull out environment variables and target an instance specific to that branch (AWS credentials pulled out of the secret store). This achieves a similar result to the āpromotionā feature in drone, where parameters can be specified at promotion time - but without the need to bake these parameters into the code. Of course, the branch naming mechanism becomes unwieldy as deployment configuration becomes more complex.
I have had less success trying to decouple references to private docker repositories. A straight forward solution would be if I could define some additional variables (either globally, or repo owner, or repos) which are substituted in the pipeline YAML pre-processing stage. For example, I could define a variable āPRIVATE_DOCKER_URLā and then use that in all my pipeline definitions to target customised image builds.
For my use case, I would be happy to have this as a global configuration for the drone server; allowing me to tightly couple my drone instance with my local private docker repository, whilst allowing others to reuse my code without making code changes. However, I can imagine that multi-tenancy use cases might want finer control.
I may have failed to spot a way of driving Drone; or a workaround (hopefully). If not, is adding custom variable substitution aligned with Droneās direction of travel?