Value gained bytes in #38 and the api job went red on a8a8330
with one line:
python/zudb/types.py:26: Value: Attribute value was changed:
None | bool | int | ... -> None | bool | int | ... | bytes | ...
Adding a member to a union is not a break. Nothing that type checked
against the old alias stops type checking against the new one. griffe
sees a type alias as an attribute and any change to an attribute's
value as breaking, and it has no way to say otherwise.
This particular red heals on its own, because the baseline on a push to
main is HEAD^ and the next commit compares against a tree that
already has bytes in it. That is why I have not chased it. It is the
next time that is the problem: every future addition to Value, and
there will be several, fails the gate on the pull request as well,
where the baseline is origin/main and stays there until the change
lands.
The job already has an escape and it is the wrong shape for this. The
second step reads:
if [ "$was" != "$now" ]; then
echo "version moved from $was to $now, so a break here is one that was declared"
griffe check zudb -s python --against "$base" || true
exit 0
fi
So the way past a false positive on one line is to move the version,
which turns the check off for that push entirely. A push that widens
Value and also deletes a method would go green. That is a poor trade
for a line that was never a break.
What it wants is a way to say this one finding is expected, per finding
rather than per push. griffe 2.2.0's CLI has no ignore, so this is
either a wrapper that filters the output against a checked in list of
accepted findings, or a newer griffe if one grew the feature. A
filtered list has the property the version bump does not: everything
not on it still fails.
Not urgent. The gate is correct today and the failure mode is a red
that has to be read and waved through, which is survivable. It stops
being survivable when somebody starts waving it through without
reading.
Valuegainedbytesin #38 and theapijob went red ona8a8330with one line:
Adding a member to a union is not a break. Nothing that type checked
against the old alias stops type checking against the new one. griffe
sees a type alias as an attribute and any change to an attribute's
value as breaking, and it has no way to say otherwise.
This particular red heals on its own, because the baseline on a push to
main is
HEAD^and the next commit compares against a tree thatalready has
bytesin it. That is why I have not chased it. It is thenext time that is the problem: every future addition to
Value, andthere will be several, fails the gate on the pull request as well,
where the baseline is
origin/mainand stays there until the changelands.
The job already has an escape and it is the wrong shape for this. The
second step reads:
So the way past a false positive on one line is to move the version,
which turns the check off for that push entirely. A push that widens
Valueand also deletes a method would go green. That is a poor tradefor a line that was never a break.
What it wants is a way to say this one finding is expected, per finding
rather than per push. griffe 2.2.0's CLI has no ignore, so this is
either a wrapper that filters the output against a checked in list of
accepted findings, or a newer griffe if one grew the feature. A
filtered list has the property the version bump does not: everything
not on it still fails.
Not urgent. The gate is correct today and the failure mode is a red
that has to be read and waved through, which is survivable. It stops
being survivable when somebody starts waving it through without
reading.