Closed
Bug 1141801
Opened 10 years ago
Closed 5 years ago
Rule change sandbox
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), enhancement, P3)
Tracking
(Not tracked)
RESOLVED
MOVED
People
(Reporter: nthomas, Unassigned)
References
Details
(Whiteboard: [lang=js])
catlee suggested a way to test out rule changes before applying them. You'd have something that lets you modify one or more rules before they affect actual requests, and check them against a set of criterion.
I interpreted the criterion as specifying a release, with the option to restrict to a particular build target/locale/OS Version/etc to simulate a query. That could save on the nitty gritty of build target strings and buildIDs in the url, but we could leave the general case there too. Then specify which mapping should be used to serve the update, and verify that's what the rules deliver.
|
||
Updated•8 years ago
|
Priority: P5 → P3
Whiteboard: [lang=js]
|
|
||
Comment 1•7 years ago
|
||
Although it's not fully fleshed out, I think bug 1369379 might be a more concrete idea about how to do this?
See Also: → 1369379
|
|
||
Comment 2•7 years ago
|
||
In some ways, implementing bug 1369379 gives us a sort-of automatic sandbox. Not a true sandbox, but we'd have a way to run queries against non-live Rules.
|
|
||
Comment 3•5 years ago
|
||
I know there's important UI bits to this, but I think the big parts are actual backend bits, so I'm moving it to that component.
Component: Applications: Balrog (frontend) → Applications: Balrog (backend)
|
|
||
Comment 4•5 years ago
|
||
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → MOVED
|
||
Updated•5 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•