Skip to content

merge queue: embarking master (6f8bd97) and #2394 together#2395

Closed
mergify[bot] wants to merge 9 commits intomasterfrom
mergify/merge-queue/5322d8c3d0
Closed

merge queue: embarking master (6f8bd97) and #2394 together#2395
mergify[bot] wants to merge 9 commits intomasterfrom
mergify/merge-queue/5322d8c3d0

Conversation

@mergify
Copy link
Copy Markdown
Contributor

@mergify mergify bot commented Mar 24, 2026

✨ The merge conditions cannot be satisfied due to failing checks. ✨

Branch master (6f8bd97) and #2394 are embarked together for merge.

This pull request has been created by Mergify to speculatively check the mergeability of #2394.
You don't need to do anything. Mergify will close this pull request automatically when it is complete.

Required conditions of queue rule default for merge:

  • any of [🛡 GitHub branch protection]:
    • check-neutral = all_ci_tests
    • check-skipped = all_ci_tests
    • check-success = all_ci_tests
  • #approved-reviews-by >= 1 [🛡 GitHub branch protection]
  • #changes-requested-reviews-by = 0 [🛡 GitHub branch protection]
  • any of [🛡 GitHub branch protection]:
    • check-success = deploy/netlify
    • check-neutral = deploy/netlify
    • check-skipped = deploy/netlify

Required conditions to stay in the queue:

---
checking_base_sha: 6f8bd975561b846eedb88141a8d6cdd860aceaa2
previous_failed_batches: []
pull_requests:
  - number: 2394
    scopes: []
scopes: []
...

iteratee and others added 9 commits March 19, 2026 16:34
At some point, this support must have disappeared. If the haddock
attribute goes away completely, then we can remove the code that checks
for it. Cabal args and the attribute work together and either can
disable haddock.
A couple of features of the stack_snapshot module extension just didn't
work. Fix them
The version from bazel_tools is deprecated and has been removed in bazel
8+

There is a version from rules_cc, from 0.1.1 onwards, but we already
have a private version in this repository. Use it everywhere
appropriate. Updating the rules_cc depedency is not straightforward.
Bazel 8 may produce an executable path that begins with "..". Make the
package extraction work correctly with this type of path.

Bump the bazel-runfiles version number in the cabal file.
bazel behaves slightly differently when requesting runfiles from an
external repository. Add a test case for that scenario.

The test case is part of a tar archive. It could be a local repository,
but only once the minimum bazel version is 7.2+. Fortunately bazel
accepts the de-facto relative file url standard, so there is no need to
resort to pulling the archive down over http.
The previous code used the dirname of the cabal file, which really
wasn't the correct thing to use. What the runfiles library is really
looking for is the cabal directory _relative_ to the repository name.
Pass in the repository from the label of the cabal library/executable
currently being built. Use that to find the correct relative location
for external repositories.
@mergify mergify bot mentioned this pull request Mar 24, 2026
@mergify mergify bot closed this Mar 24, 2026
@mergify mergify bot deleted the mergify/merge-queue/5322d8c3d0 branch March 24, 2026 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant