Ignoring `"source_code_sha"` does not work?

[ericcornelissen]

I tried to ignore "@types/.+": ["source_code_sha"] but it does not appear to work as expected as seen in this comment (revision May 4, 2025, 12:36 PM GMT+2). Before I made that change (when it was "@types/.+": ["source_code"]) it did ignore the @types/.+ packages' inaccessible commit SHA/tags finding correctly (see revision May 4, 2025, 12:07 PM GMT+2).

I would like to be able to ignore only the fact that the commit SHA/tag is not found while still requiring these packages have a valid source URL - which the configuration docs suggest should be possible.

[ericcornelissen]

A related confusion, does ignoring "source_code_sha" ignore those warnings concerning packages for which no commit SHA could be found or/and those for which no VCS tag could be found?

[randomicecube]

I would like to be able to ignore only the fact that the commit SHA/tag is not found while still requiring these packages have a valid source URL - which the configuration docs suggest should be possible.

This was a bug, thanks for reporting it! See #174

A related confusion, does ignoring "source_code_sha" ignore those warnings concerning packages for which no commit SHA could be found or/and those for which no VCS tag could be found?

The check itself verifies whether at least one of SHA or VCS tag exists, and reports if that's not the case, so ignoring it ignores these cases.

[ericcornelissen]

This was a bug, thanks for reporting it! See #174

👍

A related confusion, does ignoring "source_code_sha" ignore those warnings concerning packages for which no commit SHA could be found or/and those for which no VCS tag could be found?

The check itself verifies whether at least one of SHA or VCS tag exists, and reports if that's not the case, so ignoring it ignores these cases.

In that case the naming source_code_sha is a bit unfortunate. Perhaps you can have:

• "source_code_origin": does the package (version) specify the location from which it originates?
• "source_code_revision": is there a revision (SHA, tag, w/e) in the origin that (is supposed to) corresponds to the package version.

Or, but this would require a lot of work beyond just the config, you could separate tags (more generally mutable pointers to a revision) from SHAs (more generally immutable pointers to a revision). This would allow for a more lenient policy where tags are sufficient or a more strict policy where SHAs are required.

[randomicecube]

In that case the naming source_code_sha is a bit unfortunate

I absolutely agree, but since at the time they were implemented as part of the same check, I had to opt for one and went for SHA instead of tag because, well, vibes. I prefer the term revision though.
In your first suggestion, how would these work in combination? Would it be similar to no_source_code and 404, where the first checks if they exist or not, and the second checks if they exist AND we can find them? But how would these be referenced? Most times (if not all? other than SHAs I guess) metadata does not include specific release tag/SHA URLs, we try to track them manually.

[ericcornelissen]

I'm not 100% sure I follow, I thought my suggestion was to rename "source_code" to "source_code_origin" and "source_code_sha" to "source_code_revision". However, then I looked at the current documentation for ignoring and now I guess my suggestion is something like:

The possible specific check options to ignore are as follows (note that checks
represented as "children" of another check are ignored if the parent one is):

  - "source_code"
-   - "source_code_sha"
+   - "source_code_origin"
+     - "source_code_revision"
    - "forks"
  - "deprecated"
  - "provenance"
  - "code_signature"
  - "aliased_packages"

That is, the way I was thinking about this, in the context of ignoring, is that:

• "source_code_origin": would ignore it if there is no origin or it's unavailable (e.g. 404), by extensions this would also ignore revisions because without an origin there are no revisions.
• "source_code_revision": would ignore it only if the revision was not found, but it would still be required that there is an origin.

That is, you'd never have to use them in combination, the former subsumes the latter. I guess similar to how "source_code" subsumes "source_code_sha" currently.