diggerhq / demo-project-dependencies

demo-project-dependencies

demo-project-dependencies's Issues

Backend-based PR-level locks

Currently, PR-level locks are managed from Digger CLI directly. The benefit of this approach is that there is no need for any backend (cloud or self-hosted). But there are also drawbacks:

• Additional configuration required (different for different cloud providers)
• Limited to 3 major cloud providers
• Locks are stored "in the open" in the user's cloud account

Proposal

Implement a 4th provider of locks under pkg/locking that will support locks from a generic API, smth like this:

• PUT /<lockId> to acquire a lock
• DELETE /<lockId> to release a lock

Alternatively we can tie locks to projects:

• POST /<projectId>/lock to acquire a lock
• POST /<projectId>/unlock to release a lock

Questions:

• Should it be part of digger orchestrator backend or standalone service / function?
• In case of self-hosting, what should be the store for locks? We cannot assume any cloud provider. Or perhaps we can assume 1 of the Big 3 and move the logic of locks from the CLI as-is

depends_on should trigger dependent projects without include_patterns

It seems to make more sense to have depends_on trigger automatically, e.g. if a change occurs in a project that's a dependency for other projects, then all dependent projects are triggered