-
-
Notifications
You must be signed in to change notification settings - Fork 14.4k
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
prometheus: 2.27.1 -> 2.30.3 #141477
prometheus: 2.27.1 -> 2.30.3 #141477
Conversation
a1642ae
to
f8356c0
Compare
Copying my text from Matrix to @K900 to here, as it seems quite relevant. :) if you can validate that it runs and works in a setup that you have used with it, it would be great. I have currently set it up, and it's running fine on my instance. However, there is a dirty hack in the current PR, but I don't really see any other way. They have implemented a "module" system, that seems very hacky. But seeing as I am building the only module they currently have (codemirror-promql), then I don't think it makes sense, to actually run their build system. You can see the hack here - https://github.com/NixOS/nixpkgs/pull/141477/files#diff-ca9e5cc95e3ef1d454502e3df0bd0c621434832f1f9feef52dac9a970a5c2100R83 Also, I think that some of the things in the patchPhase, should actually just be in the configure phase. Ie. all the symbolic links, should maybe just be in configure phase. And the one where I override the build modules script, should be in the patch phase. TL;DR I am currently running this in my own setup, but would love anyone that could try it in their own current setup to validate it. I need some feedback on the hack I have made (check link above), and feedback on how to split up the |
It works great for me. One thing missing that I know is the option |
Think that should be added in a separate PR, if you have the time you could make one? :) |
560843d
to
c319107
Compare
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.
Are there new releases of exporters that are broken according to you (e.g. blackbox-exporter
)? if yes, these should be updated in here as well.
}; | ||
|
||
goPackagePath = "github.com/prometheus/prometheus"; | ||
|
||
webui = mkYarnPackage { | ||
codemirrorNode = import ./webui/codemirror-promql { |
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.
Have you tried generating a yarn.lock
on your own and use this? IIRC node2nix
causes way more work than yarn2nix
does in most cases, so I'd prefer to keep it.
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.
If we were to go this route, shouldn't we create a yarn.lock from the upstream lockfile? Seems like it wouldn't be a good idea, to run different versions than upstream are
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.
Seems to be possible with https://classic.yarnpkg.com/blog/2018/06/04/yarn-import-package-lock/
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.
I don't think we should stick with yarn, but move to npm.
Looked at this thread here - prometheus/prometheus#9198 which also links this thanos-io/thanos#4562 and it seems to be a general move.
There are some dependencies yarn can't handle as well, that npm handles well. So we could end up having a different set of dependencies than upstream, if we continue to use yarn.
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.
Agreed. If upstream is moving to npm we should do so as well.
I am not sure, an unsure where to check it. I run the node-exporter and blackbox-exporter, those both work. |
@GrahamcOfBorg test prometheus |
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.
LGTM!
@eyJhb I'm trying to upgrade to the latest prometheus-2.31.0 and I noticed they moved the web/ui package to npm workspaces. Any idea how to update your |
It just seems to be sugar on top of npm, and nothing more. Currently it just builds the two components independently, and then fixes the paths. Should that be any issue? The webui works fine when I tested it :) - Are you available on Matrix for discussing any miscommunication? :) |
The issue is that they now have a single
At the moment the package doesn't build. But maybe I can try just using that single
I'm not and TIL about Matrix. I'll look into signing up. Where can I do that? |
It seems this is ready to merge. We can do the 2.31.0 upgrade in another PR. Merging in now... |
Oh, didn't notice a new version had come out. Sorry! Thanks for merging @basvandijk ! :) |
Motivation for this change
Needs update, there are some syntax shown on ie. blackbox-exporter that does not work on the current version of prometheus (I think).
Things done
I have updated the version numbers + hashes.
However, they have changed yarn out with npm, which has caused some headache.
They have also added a module system, that is currently working OK with a hack that needs to be changed...
I have ran the prometheus tests and they pass without any issues.
TODOs
sandbox = true
set innix.conf
? (See Nix manual)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)