How to handle route conflicts in deployments
Learn how to proceed if these warnings are displayed in Run when a deployment needs to be made.
Was this helpful?
Learn how to proceed if these warnings are displayed in Run when a deployment needs to be made.
Was this helpful?
Was this helpful?
When a pipeline is ready to be deployed, you need to take a number of actions, i.e., select the size, concurrent executions, and replicas. However, it is important to pay attention to the routes specified in the API Routes in Build.
This is because if a route is specified that already exists, conflicts will occur and deployment of the same routes will not be possible.
After you have made the configurations for the deployment, the last step is to click on Deploy. But if the Additional API Routes selected in the Build phase start with a parameter, this results in an error because a route has not yet been created and must not start with a parameter.
As you can see, when you use /:product, the original path to access the pipeline will be substituted.
So, in Run, if the parameters for a route are not established, the message below will appear informing you of this and the deployment will not be able to proceed.
The correct way is to add a new route that gets a parameter - for example, /product/:id to solve this error.
Another warning that appears when a deployment is to be made but an error is found is when a route is used that already exists in a different pipeline.
As we can see in the example below, the /conflict/route has already been used in a pipeline called 123-run-routes-2.
But if we set the same route, /conflict/route, in another pipeline as shown below, the different pipelines will have identical URLs, so only one of them will be executed.
In Run, a warning before deployment informs that the route is already being used in another pipeline. So, you need to change the route in the API Routes in Build and then deploy it in Run.
To avoid this, we suggest using a naming pattern, for requests as well. This also brings some advantages, that is, greater control and security for these types of triggers (REST, HTTP and HTTP File), additional routes give more flexibility to pipelines and the user avoids double work when using legacies with less flexibility in terms of URL.