ci: use upstream BUILD file in nlohmann json

[mering]

This reduces maintenance and unblocks people from using the nlohmann_json dependency from BCR when using Bzlmod.

---

This change is 

[mering]

@scotthart @dbolduc could you please trigger the tests? Thanks!

[dbolduc]

/gcbrun

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 93.22%. Comparing base (4d30f62) to head (d812878).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #14310   +/-   ##
=======================================
  Coverage   93.22%   93.22%           
=======================================
  Files        2181     2181           
  Lines      191080   191080           
=======================================
+ Hits       178125   178128    +3     
+ Misses      12955    12952    -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[conventional-commit-lint-gcf]

🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use automerge label. Good luck human!

-- conventional-commit-lint bot
https://conventionalcommits.org/

[scotthart]

I'm concerned that the upstream BUILD.bazel file specifies alwayslink = True. Our BUILD file does not specify this and does not need it. Adding this flag will only serve to unnecessarily increase the resulting size of the eventual binaries.

[coryan]

I'm concerned that the upstream BUILD.bazel file specifies alwayslink = True. Our BUILD file does not specify this and does not need it. Adding this flag will only serve to unnecessarily increase the resulting size of the eventual binaries.

How? AFAICT, the library is header-only, it does not contain any .o files to increase the size of any binaries. The alwayslink = True seems misguided as it makes no difference, but it also does not seem to harm anything.

Furthermore, if it library had any .o files: we link the library only where it is needed (or we at least we should). I would think nothing can increase "unnecessarily" if the library is already being linked?

[coryan]

Seems like this PR needs a rebase

[mering]

Seems like this PR needs a rebase

Rebased.

[coryan]

/gcbrun

[scotthart]

My understanding is that alwayslink functions similarly to --whole-archive, perhaps I'm mistaken. But, as you correctly point out, there are no .o files in this header only library (which probably won't deviate from being header only in the future).

Reviewed 5 of 6 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @mering)

[scotthart]

The conventionalcommits failure should resolve if you edit the commit message to follow the same pattern as the PR title.

[coryan]

The conventionalcommits failure should resolve if you edit the commit message to follow the same pattern as the PR title.

correct, but we can just edit the squash commit message for the same effect (which I just did).

[mering]

Thanks to both of you for your help!

[coryan]

On the contrary, thanks for the PR. We completely missed that this dependency had introduced support for Bazel.