feat: seal api implementation (search + endpoints) - #1799
Conversation
cka-y
changed the title
|
Built on top of #1795 to match the new schema |
| # How long a criterion may keep failing its own check before the failure is confirmed and | ||
| # the seal is withdrawn. None means the status flips on the first failing day. | ||
| # | ||
| # `official` and `stable` have no grace period: they are point-in-time state checks on data | ||
| # we already hold, not observations of a fetched artifact, so there is no transient failure | ||
| # to debounce. | ||
| GRACE_PERIODS: Final[Dict[SealCriterionName, Optional[timedelta]]] = { | ||
| SealCriterionName.OFFICIAL: None, | ||
| SealCriterionName.STABLE: None, | ||
| SealCriterionName.AVAILABLE: timedelta(days=14), | ||
| SealCriterionName.COMPLIANT: timedelta(days=30), | ||
| SealCriterionName.FRESH_COVERAGE: timedelta(days=7), | ||
| SealCriterionName.FRESH_CONTINUOUS: timedelta(days=7), | ||
| } |
There was a problem hiding this comment.
@cka-y Revision:
SealCriterionName.OFFICIAL: None,
SealCriterionName.STABLE: None,
SealCriterionName.AVAILABLE: timedelta(days=14),
SealCriterionName.COMPLIANT: timedelta(days=30),
SealCriterionName.FRESH_COVERAGE: timedelta(days=14),
SealCriterionName.FRESH_CONTINUOUS: None,
| # A criterion that recovers from a confirmed failure is put on probation: it must then go | ||
| # this long with no observed failure before it can contribute to the seal again. This is the | ||
| # "six clean months" rule - losing the seal is not undone by a single good day. | ||
| PROBATION_PERIOD: Final[timedelta] = timedelta(days=180) | ||
|
|
||
| # `official` and `stable` are exempt for the same reason they have no grace period. A feed | ||
| # that is marked official again is official again; there is no track record to rebuild. | ||
| PROBATION_PERIODS: Final[Dict[SealCriterionName, Optional[timedelta]]] = { | ||
| SealCriterionName.OFFICIAL: None, | ||
| SealCriterionName.STABLE: None, | ||
| SealCriterionName.AVAILABLE: PROBATION_PERIOD, | ||
| SealCriterionName.COMPLIANT: PROBATION_PERIOD, | ||
| SealCriterionName.FRESH_COVERAGE: PROBATION_PERIOD, | ||
| SealCriterionName.FRESH_CONTINUOUS: PROBATION_PERIOD, | ||
| } | ||
|
|
There was a problem hiding this comment.
Stable is subject to the probation period (it takes 6 months to earn it). Not sure if that's treated as part of the criteria though in the code and therefore an additional probation period doesn't need to be added
There was a problem hiding this comment.
i was under the impression that it would be as part of the code for the criterion.
question to clarify: if is_producer_url_unstable flag flipped from true to false, do we need to wait 6 months before allowing the criterion to pass given that the feed is older than 6months?
There was a problem hiding this comment.
Got it, in that case then no probation period.
Re: question: Nope! Assuming the feed has 6 months of history, the feed would automatically show up as Stable. The only reason it would flip is because of a gap in our manual review, not that the URL has changed, so there's no wait time.
3 participants
Summary:
Summarize the changes in the pull request including how it relates to any issues (include the #number, or link them).
Expected behavior:
Explain and/or show screenshots for how you expect the pull request to work in your testing (in case other devices exhibit different behavior).
Testing tips:
Provide tips, procedures and sample files on how to test the feature.
Testers are invited to follow the tips AND to try anything they deem relevant outside the bounds of the testing tips.
Please make sure these boxes are checked before submitting your pull request - thanks!
./scripts/api-tests.shto make sure you didn't break anything