You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently our lock resource names (PR locks) are of the format diggerhq/demo-opentofu#dev, so its repo org, repo name and project name. However as we expand to multiple CI systems this will cause conflicts of names, therefore I propose to add the vCS name to the resource name to avoid this naming conflicts:
In that way we guarantee uniqueness in digger cloud
This is more a concern for the cloud offering rather than the self-hosted instances or backendless modes, however applying globally will safeguard against any future conflicts.
If we change the name then existing locks will be invalidated. In order to make it a graceful move we can only apply this change to the digger_locks database table (other backend cloud-based locks such as dynamoDB will remain the same). This then makes it a graceful change and therefore no lock invalidation will occur
The text was updated successfully, but these errors were encountered:
Currently our lock resource names (PR locks) are of the format diggerhq/demo-opentofu#dev, so its repo org, repo name and project name. However as we expand to multiple CI systems this will cause conflicts of names, therefore I propose to add the vCS name to the resource name to avoid this naming conflicts:
github#diggerhq/demo-opentofu#dev
gitlab#diggerdev/demo-opentofu#prod
In that way we guarantee uniqueness in digger cloud
This is more a concern for the cloud offering rather than the self-hosted instances or backendless modes, however applying globally will safeguard against any future conflicts.
If we change the name then existing locks will be invalidated. In order to make it a graceful move we can only apply this change to the digger_locks database table (other backend cloud-based locks such as dynamoDB will remain the same). This then makes it a graceful change and therefore no lock invalidation will occur
The text was updated successfully, but these errors were encountered: