Up until now, the frontend was taken from `srcStatic`, i.e. prebuilt
from upstream. I recall at least three cases[1][2][3] where we got a hash
mismatch eventually.
Rather than spending time finding out whether or not it's a supply-chain
attack or just a build issue, I decided to implement a source-build now
with the following benefits:
* It's now actually possible to apply patches for Grafana's frontend.
* We rely a little less on third-party build systems.
Of course, patching potential vulnerabilities in transitive frontend
dependencies is still hard (let alone discovering that this package is
affected!), but that's a fundamental issue we have in nixpkgs and I
won't invent a half-baked solution just for this package, I still
consider this a step into the right direction.
The build itself mainly orients on the `yarn` commands used in the
upstream Makefile[4]. However, we can't use `fetchYarnDeps` here because
yarn v2 (a.k.a. `berry`) is in use which is why the same was done as in
`hedgedoc`, writing a custom FoD that downloads all dependencies and
writes the offline cache into `$out`[5].
Additionally there are two more notable differences to upstream:
* We patch out every dependency to `@grafana/e2e` and `cypress`. The
first is a dependency on the latter in another version and the latter
downloads random blobs from the Internet in postInstall. Since it's a
testing framework (and the `e2e` package apparently a testing
library), I decided it's not worth the effort and patched it out
everywhere.
* There was a `zoneinfo.zip` in `$out/share/grafana/tools` that was
installed from `srcStatic`. This only seems to be used on Windows[6]
and that's not supported by this package, so I decided to drop it.
[1] https://github.com/NixOS/nixpkgs/pull/251479
[2] https://github.com/NixOS/nixpkgs/pull/130201
[3] https://github.com/NixOS/nixpkgs/pull/104794
[4] https://github.com/grafana/grafana/blob/v10.3.1/Makefile
[5] https://github.com/NixOS/nixpkgs/pull/245170
[6] https://github.com/grafana/grafana/blob/v10.3.1/pkg/setting/setting.go#L1012-L1014
ChangeLog: https://github.com/grafana/grafana/releases/tag/v10.2.3
Changed `preBuild` to `postConfigure` since the latter is a hook that's
only executed in the actual build, not in the gomod FoD. This is a dirty
hack because apparently the removal of `pkg/util/xorm/go.{mod,sum}`
breaks the module download now, but not removing it breaks the build
later (as documented in the comment above).
A nice side-effect is that we don't do all the `go generate`/`wire`
invocations twice per build.
stdenv.targetPlatform really shouldn't be used by software that
doesn't generate or manipulate binaries. I reviewed all uses of
targetPlatform outside of pkgs/development/compilers and pkgs/stdenv
and replaced those which weren't involved in something which fits
these criteria.
Conflicts:
- pkgs/tools/networking/shadowfox/default.nix between e989daa65f and 1c29673fcc
- pkgs/tools/networking/wuzz/default.nix between 7d80417710 and 1c29673fcc
In 787af0f79f
I had to change ${go-modules} to $goModules to allow overrideAttrs to work;
However, env vars cannot contain -, so i had to change go-modules too.
This in turn broke nix-update because it uses the go-modules attr.
Instead of making nix-update more complicated, make go-modules naming match cargoDeps.
`fd --type f | xargs sd '\bgo-modules\b' 'goModules'`
and revert change to pkgs/applications/misc/dstask/default.nix
and pkgs/servers/http/dave/default.nix
and pkgs/os-specific/darwin/plistwatch/default.nix
release note added
It's weird but this single test started failing in this staging-next
iteration, on all four 64-bit platforms.
I thought this will be better than not having any grafana,
as it's only a single test and our .tests still build.
Sadly, upstream doesn't publish proper changelogs anymore[1] and there's
also quite a gap - this is the first time a release was published for
9.4.x since 9.4.3, so I decided to skim through the commit log on my own[2].
While there are no apparent problematic changes for us, but only
bugfixes, internal changes and a few doc fixes, I found at least one
security patch[3] fixing XSS in the graphite datasource settings, hence
the corresponding PR will get a security label.
[1] https://github.com/grafana/grafana/releases/tag/v9.4.7
/ adcdf190bb
[2] https://github.com/grafana/grafana/compare/v9.4.3...v9.4.7
[3] ef2eb2b6bf
ChangeLog: ae90f73b78/CHANGELOG.md (942-2023-03-02)
Also synced up the `go generate` calls from upstream's Makefile
with our buildscript.
Finally, I removed the `go.{mod,sum}` files from the vendored `xorm` in
`pkg/util`. This was to work around the following build error:
main module (github.com/grafana/grafana) does not contain package github.com/grafana/grafana/pkg/util/xorm
Not entirely sure why, but I guess that the presence of these files
confused our build-script and it wrongly assumed that
github.com/grafana/.../xorm didn't exist (while a different xorm
according to the values in `go.mod` existed).
