What problem would this solve?
Gitea currently has several concepts that express relationships between issues and pull requests:
- references (
#123, owner/repo#123)
- issue dependencies
- pull requests targeting other branches (which can be used to form stacked PR workflows)
However, there does not appear to be a single, first-class graph describing dependencies between work items.
As a result, higher-level workflows such as:
- dependent pull requests
- stacked pull requests
- cross-repository pull request dependencies
- dependency visualization
- merge blocking based on prerequisites
either cannot be implemented or require ad-hoc logic tied to specific workflows.
What do you propose?
Introduce a generic dependency model between Issues and Pull Requests.
Conceptually:
WorkItem A ---> WorkItem B
meaning:
WorkItem A depends on WorkItem B.
Since pull requests are already represented internally as issues with additional metadata, this could potentially be implemented as a generic dependency relation between issue records.
Example schema (illustrative only):
type Dependency struct {
ID int64
SourceID int64
TargetID int64
Type string
}or any equivalent representation.
Desired properties
- Works for Issue → Issue dependencies.
- Works for Pull Request → Pull Request dependencies.
- Works for Issue → Pull Request dependencies.
- Works across repositories.
- Exposed through REST and GraphQL APIs.
- Queryable in both directions ("depends on" and "blocked by").
Potential applications
The dependency graph could serve as a common foundation for:
- stacked pull requests
- cross-repository pull request dependencies
- release coordination
- package dependency workflows
- merge gating
- dependency visualization
without requiring each feature to introduce its own relationship model.
Benefits
Creating a generic dependency layer first would allow future workflow features to build on a shared foundation rather than introducing multiple partially-overlapping mechanisms.
What problem would this solve?
Gitea currently has several concepts that express relationships between issues and pull requests:
#123,owner/repo#123)However, there does not appear to be a single, first-class graph describing dependencies between work items.
As a result, higher-level workflows such as:
either cannot be implemented or require ad-hoc logic tied to specific workflows.
What do you propose?
Introduce a generic dependency model between Issues and Pull Requests.
Conceptually:
meaning:
Since pull requests are already represented internally as issues with additional metadata, this could potentially be implemented as a generic dependency relation between issue records.
Example schema (illustrative only):
or any equivalent representation.
Desired properties
Potential applications
The dependency graph could serve as a common foundation for:
without requiring each feature to introduce its own relationship model.
Benefits
Creating a generic dependency layer first would allow future workflow features to build on a shared foundation rather than introducing multiple partially-overlapping mechanisms.