Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

doc: emphasize trade-off between versionCheckHook and testers.testVersion #344321

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+4 −2
Open

doc: emphasize trade-off between versionCheckHook and testers.testVersion #344321

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion doc/build-helpers/testers.chapter.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,7 +169,7 @@ The build will fail if `shellcheck` finds any issues.

Checks that the output from running a command contains the specified version string in it as a whole word.

NOTE: In most cases, [`versionCheckHook`](#versioncheckhook) should be preferred, but this function is provided and documented here anyway. The motivation for adding either tests would be:
NOTE: If you want a version check failure to trigger a build failure, then [`versionCheckHook`](#versioncheckhook) is preferred. The motivation for adding either tests would be:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good start for the sentence, but I don't think that the average contributor knows whether they would like to trigger a build failure or not. Perhaps here, or in the NOTE at the end of the diff we can lay out arguments why would someone want the failure to block and when not?

Personally I don't see a reason why it shouldn't block.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some upstreams do not have a bump script but instead do releases by hand. This risks tagging versions where the version provided in e.g. package.json is incorrect.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some upstreams do not have a bump script but instead do releases by hand. This risks tagging versions where the version provided in e.g. package.json is incorrect.

Isn't that a good sign that the package.json should be patched? and that upstream would want to know about that? And perhaps it also means that users reporting upsteram bugs with that incorrect version would confuse them?

Copy link
Member Author

@pbsds pbsds Sep 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, but we don't have any large-scale automated reporting on r-ryantm bump failures yet (this may be subject to change), meaning version check failures could make updates stop coming in

EDIT: that argument applies to any sanity-checks not put in passthru.tests

Copy link
Member Author

@pbsds pbsds Sep 25, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here are some arguments for and against. I'm not sure whether including it is beneficial, but I can do it if you prefer so. Please help me flesh out the arguments in that case :)

Cases for versionCheckHook

* Stricter, blocks build on version check failure
* Requires the entrypoint to be hermetic enough to print its version

Cases for testers.testVersion

* Does not block build on version check failure
    * The output of potentially long running builds are thus not discarded
    * Bot updates such as r-ryantm will happen more often, in turn triggering maintainer pings and review.
* Works with non-hermetic entrypoints, dependant on certain environment variables

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: that argument applies to any sanity-checks not put in passthru.tests

Sanity checks other then versionCheckHook not in passthru.tests? What do you mean?

  • Requires the entrypoint to be hermetic enough to print its version

But that's also a case to not use any version test :). Also, people may not understand what is an entrypoint, or what do you mean by "hermetic".

  • Bot updates such as r-ryantm will happen more often, in turn triggering maintainer pings and review.

Isn't this correct only in the rare case where upstream released the new version manually and forgot to update the VERSION file or package.json version or whatever? Also, I wonder whether r-ryantm will notice that and not even open a PR, as you may have noticed that it says every time: "found ${version} with grep in /nix/store/....`.

  • Works with non-hermetic entrypoints, dependant on certain environment variables

So if by "hermetic" you mean that an executable may need an environment variable like $HOME to even do the simple version print, that is not explained well with this phrasing. An example of such a case was observed here: https://github.com/NixOS/nixpkgs/pull/339197/files#diff-dc99f6cd821b428eaa2723c4ef39f37283f34ab8c1c430c9b6a8963e64b5a24cR88-R89, and indeed it is worth mentioning, but I'm not sure yet where. Also, in the future I might add support for inheriting environment variables when trying to get version in versionCheckHook, and then this won't be an issue.

  • Does not block build on version check failure
    • The output of potentially long running builds are thus not discarded

I would agree upon something like this:

If you have a long and heavy to build package that you are not yet sure how to test it's version print or if it has any, then you may want to postpone the addition of versionCheckHook to a more mature state of the package and it's expression in Nixpkgs.


- Catch dynamic linking errors and such and missing environment variables that should be added by wrapping.
- Probable protection against accidentally building the wrong version, for example when using an "old" hash in a fixed-output derivation.
Expand Down
4 changes: 3 additions & 1 deletion doc/hooks/versionCheckHook.section.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# versionCheckHook {#versioncheckhook}

This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. You use it like this:
This hook adds a `versionCheckPhase` to the [`preInstallCheckHooks`](#ssec-installCheck-phase) that runs the main program of the derivation with a `--help` or `--version` argument, and checks that the `${version}` string is found in that output. If the test fails then the whole build will fail. You use it like this:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's great 👍.


```nix
{
Expand Down Expand Up @@ -33,3 +33,5 @@ The variables that this phase control are:
- `versionCheckProgramArg`: The argument that needs to be passed to `versionCheckProgram`. If undefined the hook tries first `--help` and then `--version`. Examples: `version`, `-V`, `-v`.
- `preVersionCheck`: A hook to run before the check is done.
- `postVersionCheck`: A hook to run after the check is done.

NOTE: If you want the version check to be a sanity test rather than a build blocker, then [`testers.testVersion`](#tester-testVersion) is preferred. This will for example better accommodate precarious or frenetic upstreams.