Skip to content
GitLab Next
  • Menu
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • D declarative-policy
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 10
    • Issues 10
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 2
    • Merge requests 2
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • ruby
  • gems
  • declarative-policy
  • Issues
  • #14
Closed
Open
Issue created Jun 08, 2021 by Alex Kalderimis@alexkalderimis☀Maintainer

Add reverse dependency analysis

When conditions change, or are invalidated, it would be nice to be able to selectively invalidate particular cached results. Conditions themselves are fairly straightforward, but the difficulty is DeclarativePolicy::Runner objects, which cache a write-once @state to represent their result.

If you know which ability on which needs invalidating, then it is easy enough to do so by setting the @state to nil on the Policy#runner(ability) (we do need to support cache invalidation however).

But if all you know is the condition, then identifying runners which need invalidation is impossible.

Proposal

Either add reverse-dependency analysis (i.e., given a condition, tell me what abilities on which policies could be affected). Given the dynamic nature of class loading, this is probably hard-to-impossible.

A more realistic alternative is probably to record the conditions that were evaluated during the processing of a runner, and use this to find any existing cached runners that need invalidation.

Assignee
Assign to
Time tracking