-
-
Notifications
You must be signed in to change notification settings - Fork 306
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.
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
Running builds view: show build step names #1372
base: master
Are you sure you want to change the base?
Conversation
When using Hydra to build machine configurations, you'll often see "nixosConfigurations.foo" five times, i.e. for each build step being run. This isn't very helpful I think because in such a case, a single build step can also be compiling the Linux kernel. This change also fetches the `drvpath` and `type` from the `buildsteps` relation. We're already joining it, so this doesn't make much difference (confirmed via query logging that this doesn't cause extra SQL queries). Unfortunately build steps don't have a human readable name, so I'm deriving it from the drvpath by stripping away the hash (assuming that it'll never contain a `-` and that `/nix/store/` is used as prefix). I decided against using the Nix bindings for that to avoid too much overhead due to store operations for each build step.
Annoyingly that page already takes >20s to load, but whether that is related to this change, or whether it was previously this slow (it was slow), is probably something you can tell. |
We could skip that part in the UI if step name equals package name. It's only really interesting if you have something like a VM test or nixos configuration with lots of steps before. |
When building e.g. nixpkgs, the "Running builds" view will mostly look like this hello.x86_64-linux (Build of hello-X.Y) exa.x86_64-linux (Build of exa-X.Y) ... This doesn't provide any useful information. Showing the step name only makes sense if it's not a child of the job's derivation. With this patch, that information will only be shown if the drv name (i.e. w/o `/nix/store/` prefix, .drv ext & hash) is not equal to the drv name of the job itself (build.nixname).
I didn't get to deploy bd380f6 yet, but locally it seems as if it'd resolve the issue about showing too much information. |
@@ -91,6 +91,17 @@ BLOCK renderDuration; | |||
duration % 60 %]s[% | |||
END; | |||
|
|||
BLOCK renderDrvInfo; | |||
drvname = step.drvpath | |||
.substr(11) # strip `/nix/store/` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
$Nix::Config::storeDir
I think this is a thing, can you use it?
So you are fine with the performance of this, now that it deployed? |
No, https://hydra.nixos.org/status is really slow compared to https://hydra.nixos.org/machines, while vaguely showing the same things. |
When using Hydra to build machine configurations, you'll often see "nixosConfigurations.foo" five times, i.e. for each build step being run. This isn't very helpful I think because in such a case, a single build step can also be compiling the Linux kernel.
This change also fetches the
drvpath
andtype
from thebuildsteps
relation. We're already joining it, so this doesn't make much difference (confirmed via query logging that this doesn't cause extra SQL queries).Unfortunately build steps don't have a human readable name, so I'm deriving it from the drvpath by stripping away the hash (assuming that it'll never contain a
-
and that/nix/store/
is used as prefix). I decided against using the Nix bindings for that to avoid too much overhead due to store operations for each build step.