Bump junit from 4.11 to 4.13.1 in /testprojects/maven_layout/protolib-test #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [junit](https://github.com/junit-team/junit4) from 4.11 to 4.13.1. - [Release notes](https://github.com/junit-team/junit4/releases) - [Changelog](https://github.com/junit-team/junit4/blob/main/doc/ReleaseNotes4.11.md) - [Commits](junit-team/junit4@r4.11...r4.13.1) Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
dependabot
bot
deleted the
dependabot/maven/testprojects/maven_layout/protolib-test/junit-junit-4.13.1
branch
asherf
pushed a commit
that referenced
this pull request
Jul 30, 2021
This shows how we can convert types defined in Python into Rust, e.g. `PathGlobs`.
Whereas we used to use a free function to do the conversion and asked for `PyObject` in the FFI function, now we implement the trait `FromPyObject` on a wrapper type `PyPathGlobs` so that we can request it directly in the function signature. This is more idiomatic and makes the `#[pyfunction]` more clear what it does.
We also now directly use PyO3's `.getattr()` and `.extract()` at callsites, rather than using our custom `getattr()` functions that wrapped those with Rust-Cpython. This removes a layer of indirection and doesn't noticeably increase boilerplate at callsites - it in fact reduces some because it's easier to chain `.getattr()` multiple times.
At least for now, we don't use `Value`, which is an `Arc` around a Rust-CPython `PyObject`. We were using that because cloning with Rust-CPython requires the GIL. Here, we're able to clone w/o requiring the GIL (in `PyPathGlobs.parse()`), so I went with a simpler implementation. Some benefits of avoiding `Value` are a) better type safety and b) avoiding a lock. We may end up needing `Value` at the end of the day, but we can add this back.
### Benchmark
PyO3 does have slightly worse performance with this diff:
```diff
diff --git a/src/python/pants/bin/pants_loader.py b/src/python/pants/bin/pants_loader.py
index 10c8b406b..ec9ef50bf 100644
--- a/src/python/pants/bin/pants_loader.py
+++ b/src/python/pants/bin/pants_loader.py
@@ -126,4 +126,8 @@ def main() -> None:
if __name__ == "__main__":
- main()
+ from pants.engine.internals.native_engine import match_path_globs
+ from pants.engine.fs import PathGlobs
+
+ x = match_path_globs(PathGlobs(["**/*.txt"]), tuple(f"foo/{i}.txt" for i in range(1_000_000)))
+ # main()
```
Before:
```
❯ hyperfine --warmup 1 --runs=100 './pants'
Benchmark #1: ./pants
Time (mean ± σ): 712.3 ms ± 4.6 ms [User: 587.7 ms, System: 103.3 ms]
Range (min … max): 701.0 ms … 722.9 ms 100 runs
```
After:
```
❯ hyperfine --warmup 1 --runs=100 './pants'
Benchmark #1: ./pants
Time (mean ± σ): 732.7 ms ± 8.0 ms [User: 610.8 ms, System: 100.2 ms]
Range (min … max): 720.5 ms … 778.0 ms 100 runs
```
Another `after` benchmark run with fewer apps on my machine shows `726.1 ms ± 4.9 ms [User: 610.0 ms, System: 94.8 ms]`. Note that User is still the same, and only System changes. So this seems to be an actual slowdown.
I am not yet sure why, but can profile if this is concerning.
[ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
Sep 9, 2021
…dependency inference (pantsbuild#12818) Omitting these packages would break backport libraries (such as dataclasses). Performance impact is negligible since the dependency graph has already been gathered. Benchmarks using `$ hyperfine --warmup=1 --runs=10 './pants --no-remote-cache-{read,write} --no-pantsd dependencies ::'` Before these changes (omitting stdlib dependencies): ```bash Benchmark #1: ./pants --no-remote-cache-{read,write} --no-pantsd dependencies :: Time (mean ± σ): 8.852 s ± 0.105 s [User: 8.612 s, System: 5.314 s] Range (min … max): 8.702 s … 9.107 s 10 runs ``` After changes (with stdlib dependency inference) ```bash Benchmark #1: ./pants --no-remote-cache-{read,write} --no-pantsd dependencies :: Time (mean ± σ): 8.854 s ± 0.123 s [User: 8.619 s, System: 5.333 s] Range (min … max): 8.682 s … 9.111 s 10 runs ``` [ci skip-rust] [ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
Oct 9, 2021
…ze external packages (pantsbuild#13128) We were running `go list -json` much more frequently than necessary. We run it once per module to generate `_go_external_package` targets, but then we would rerun it on each package within the module. Those each often took 5-9 seconds, so this was atrocious for performance. Instead, we can simply run it once per module and leverage the engine's memoization to avoid re-running. This refactors our external module code so that it no longer interacts at all with the Target API, which reduces coupling. We rename things like the file to `external_pkg.py` so that only the `ExternalModuleInfo` and `ExternalPkgInfo` types are exposed. Notably, we no longer use `ResolvedGoPackage` for external code, which allows us to ignore lots of irrelevant fields like `test_imports`. ### `dependencies` benchmark This requires changing this line to use `Targets` so that generated targets have their dependencies resolved too: https://github.com/pantsbuild/pants/blob/a744978d2badd06509cc6e8091c14220bed3aff6/src/python/pants/backend/project_info/dependencies.py#L94 Before (I aborted after 1 run because it was so slow): ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache dependencies ::' Current estimate: 344.640 s ``` After: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache dependencies ::' Time (mean ± σ): 26.501 s ± 1.537 s [User: 29.554 s, System: 24.115 s] Range (min … max): 24.928 s … 28.763 s 5 runs ``` ### `package` benchmark Compilation is faster now too, as we no longer need to run `go list` to determine the `.go` and `.s` files. It's already eagerly computed beforehand. Before: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache package ::' Benchmark #1: ./pants_from_sources --no-pantsd --no-process-execution-local-cache package :: Time (mean ± σ): 54.981 s ± 1.441 s [User: 70.577 s, System: 81.823 s] Range (min … max): 53.426 s … 57.188 s 5 runs ``` After: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache package ::' Time (mean ± σ): 33.777 s ± 0.248 s [User: 39.221 s, System: 39.389 s] Range (min … max): 33.517 s … 34.062 s 5 runs ``` [ci skip-rust] [ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
Oct 9, 2021
Closes pantsbuild#13049. This greatly reduces boilerplate and also allows us to make some fields required like `import_path` and `subpath`, so that we don't have to calculate those in consuming rules like `build_go_pkg.py`. ## The address format The generated address looks like `project#./dir`. @tdyas offered that this is intuitive for Go developers because they have to say `go build ./dir` already with the leading `./`. This solves how to represent when the `_go_internal_package` is in the same dir as the `go_mod`: `project#./`. This also makes very clear the difference from external packages like `project#rsc.io/quote` vs. internal packages like `project#./dir`. ## Improves dependency inference Now that the `import_path` field is required for both `_go_internal_package` and `_go_external_package`, we can create a global mapping of `import_path -> pkg_target`. This is necessary for pantsbuild#13114. This also improves performance. We don't need to call `ResolvedGoPackage` on all the candidate targets a package might depend on to calculate their import paths. We do still need it when resolving the deps of a particular `_go_internal_package`, but we can be lazier when we call that codepath in not evaluating all candidate targets. ### `dependencies` benchmark As expected, there is no difference because we are finding the dependencies of everything, so we still have to call `ResolvedGoPackage`. The perf gains are only in things sometimes being less eager, which isn't the case here. Before: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache dependencies ::' Time (mean ± σ): 26.501 s ± 1.537 s [User: 29.554 s, System: 24.115 s] Range (min … max): 24.928 s … 28.763 s 5 runs ``` After: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache dependencies ::' Time (mean ± σ): 26.359 s ± 0.526 s [User: 29.600 s, System: 23.769 s] Range (min … max): 25.625 s … 26.993 s 5 runs ``` ### `package` benchmark Before: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache package ::' Time (mean ± σ): 33.777 s ± 0.248 s [User: 39.221 s, System: 39.389 s] Range (min … max): 33.517 s … 34.062 s 5 runs ``` After: ``` ❯ hyperfine -r 5 './pants_from_sources --no-pantsd --no-process-execution-local-cache package ::' Benchmark #1: ./pants_from_sources --no-pantsd --no-process-execution-local-cache package :: Time (mean ± σ): 31.049 s ± 0.702 s [User: 40.606 s, System: 40.537 s] Range (min … max): 30.512 s … 32.273 s 5 runs ``` ## TODO: fix `go_binary` inference of `main` field pantsbuild#13117 added inference of the `main` field for `go_binary`, that it defaults to the `go_package` defined in that directory. But target generation no longer generates targets actually in each directory. All generated targets are "located" in the BUILD file of the `go_mod`, i.e. their `spec_path` is set to that. So it no longer looks to `AddressSpecs` like there are any targets in each subdirectory, and there are >1 `_go_internal_package` targets in the `go_mod` dir. Instead, we should use the `subpath` field to determine what directory the targets correspond to. [ci skip-rust] [ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
Oct 18, 2021
…inference, only `python_source` and `python_test` targets (pantsbuild#13231) Now our Python code operates on `python_source` and `python_test` targets. This causes some changes. ### Dependency inference Dependency inference no longer runs on `python_sources` and `python_tests`, only `python_source` and `python_test`. That applies to import analysis, conftest.py, and `__init__.py`. This actually speeds up dependency inference! We no longer run `import_parser.py` twice on the same files. Before: ``` ❯ hyperfine -r 10 './pants --no-process-execution-local-cache --no-pantsd dependencies src/python::' Benchmark #1: ./pants --no-process-execution-local-cache --no-pantsd dependencies src/python:: Time (mean ± σ): 7.650 s ± 0.741 s [User: 5.794 s, System: 2.141 s] Range (min … max): 7.250 s … 9.673 s 10 runs ``` After: ``` ❯ hyperfine -r 10 './pants --no-process-execution-local-cache --no-pantsd dependencies src/python::' Benchmark #1: ./pants --no-process-execution-local-cache --no-pantsd dependencies src/python:: Time (mean ± σ): 5.998 s ± 0.279 s [User: 3.524 s, System: 0.903 s] Range (min … max): 5.708 s … 6.688 s 10 runs ``` It means that `./pants dependencies src/py:lib` now only has explicitly declared dependencies. You have to use `--transitive` to get the results of dep inference. Thanks to this change, we can simplify `import_parser.py` to assume there is only one file. ### Lockfile generation When determining the interpreter constraints to use, we now look at generated targets, not target generators. We only run over the `python_source` and `python_test` targets that actually will be used. This makes us future-proof to an `overrides` field adding `skip_tool` to only some of the files. I think it also fixes our dependency resolution for Pylint looking at direct deps? ### `FieldSet.opt_out` no longer worries about file targets Pytest and MyPy used to skip running on non-file targets. That can be removed now. This unblocks allowing you to explicitly define a `python_source`/`python_test` target.
asherf
pushed a commit
that referenced
this pull request
Oct 23, 2021
This lets you compile a package without needing to run tests or package a binary. Note that you can only directly compile a first-party package - to check if a third-party package is buildable, it must be a dependency of a first-party package. Works around pantsbuild#13175. This does not yet have an optimal UX. It's overly chatty: ``` ❯ ./pants check testprojects/src/go:: 13:36:38.57 [INFO] Initializing scheduler... 13:36:39.20 [INFO] Scheduler initialized. 13:36:39.71 [ERROR] Completed: pants.backend.go.goals.check.check_go - go failed (exit code 1). Partition #1 - github.com/pantsbuild/pants/testprojects/src/go/pants_test: ./testprojects/src/go/pants_test/foo.go:3:1: syntax error: non-declaration statement outside function body Partition #2 - github.com/pantsbuild/pants/testprojects/src/go/pants_test/bar: 𐄂 go failed. ``` We also should be streaming the result of each compilation as it happens, which has an added benefit of that output happening when compilation happens as a side effect of `run`, `package`, and `test`. Those fixes will be in a followup. [ci skip-rust] [ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
Nov 7, 2021
Before: ``` ❯ ./pants check testprojects/src/go:: 14:51:39.15 [INFO] Completed: pants.backend.go.goals.check.check_go - go succeeded. Partition #1 - github.com/pantsbuild/pants/testprojects/src/go/pants_test: Partition #2 - github.com/pantsbuild/pants/testprojects/src/go/pants_test/bar: ✓ go succeeded. ``` ``` ❯ ./pants check testprojects/src/go:: 14:52:54.54 [ERROR] Completed: pants.backend.go.goals.check.check_go - go failed (exit code 1). Partition #1 - github.com/pantsbuild/pants/testprojects/src/go/pants_test: ./testprojects/src/go/pants_test/foo.go:3:1: syntax error: non-declaration statement outside function body Partition #2 - github.com/pantsbuild/pants/testprojects/src/go/pants_test/bar: 𐄂 go failed. ``` After: ``` ❯ ./pants check testprojects/src/go:: 14:20:40.79 [INFO] Completed: Check Go compilation - go succeeded. ✓ go compile succeeded. ``` ``` ❯ ./pants check testprojects/src/go:: 14:23:16.18 [ERROR] Completed: Compile with Go - github.com/pantsbuild/pants/testprojects/src/go/pants_test failed (exit code 1). ./testprojects/src/go/pants_test/foo.go:3:1: syntax error: non-declaration statement outside function body 14:23:16.18 [ERROR] Completed: Check Go compilation - go failed (exit code 1). 𐄂 go compile failed. ``` That is, we now: - Stream results for each package, rather than waiting to batch at the very end. - Don't log the `Partition #1` part, which is verbose and confusing. - Log success at DEBUG level, rather than INFO level, for less noise. (Reminder: these workunits will show up in the dynamic UI still) [ci skip-rust]
asherf
pushed a commit
that referenced
this pull request
Nov 7, 2021
In pathological cases of very small `@rule` bodies or extreme graph shapes, cycle detection in the `Graph` can be very expensive. This cost can be challenging to detect in production, but it does occasionally show up as hot, particularly while cleaning graphs (since that skips all `@rule` logic). That's precisely when we do not want to be spending any extraneous time on formalities.
This change moves to asynchronously checking for cycles in Running nodes in the `Graph`. Checking in the background has two advantages: 1. cycle detection is batched across the entire graph, rather than per-edge-addition, and 2. in most cases, successful Nodes never need to be checked while running.
We also add two pathological graph shape benchmarks, which show significant improvement:
* `main`:
```
Benchmark #1: ./pants test --force --no-pytest-timeouts src/python/pants/engine/internals/engine_benchmarks_test.py
Time (mean ± σ): 247.157 s ± 9.095 s [User: 872.4 ms, System: 305.2 ms]
Range (min … max): 240.523 s … 266.031 s 10 runs
```
* this branch:
```
Benchmark #1: ./pants test --force --no-pytest-timeouts src/python/pants/engine/internals/engine_benchmarks_test.py
Time (mean ± σ): 34.779 s ± 4.625 s [User: 889.1 ms, System: 303.5 ms]
Range (min … max): 32.246 s … 47.491 s 10 runs
```
asherf
pushed a commit
that referenced
this pull request
Nov 16, 2021
See pantsbuild#12110 for the original motivation. ## Why migrate Beyond the APIs requiring much less boilerplate and being more ergonomic (e.g. the `.call0()` and `call1()` variants of `.call()`), I think the biggest benefit is clearer modeling for when the GIL is held. With PyO3, the two [core types](https://pyo3.rs/v0.15.0/types.html) are `&PyAny` and `PyObject` (aka `Py<PyAny`). `&PyAny` is always a reference with the same lifetime as the `Python` token, which represents when the GIL is used. Whenever you want to do Python operations in Rust, like `.getattr()`, you use `&PyAny`. `PyObject` and any `Py<T>` are GIL-independent. In contrast, rust-cpython only had `PyObject` and `&PyObject`. It passed around `Python` as an argument to any Python functions like `.getattr()`. -- An additional benefit is that using proc macros instead of declarative macros means PyCharm no longer hangs for me when working in the `engine/` crate! PyCharm does much better w/ proc macros, and things feel zippy now like autocomplete working. ## Migration strategy I tried originally doing an incremental strategy, most recently with pantsbuild#12451, which proved technically infeasible. This PR completely swaps Rust-Cpython with PyO3, but tries to minimize the diff. It only makes changes when it was too difficult to get working with PyO3. For example, `interface.rs` is far too big, but this keeps the same organization as before. For now, we still have the `native_engine_pyo3` extension along with `native_engine`. That will be consolidated in a followup. ## Benchmark Before: ``` ❯ hyperfine -w 1 -r 10 './pants --no-pantsd list ::' Benchmark #1: ./pants --no-pantsd list :: Time (mean ± σ): 2.170 s ± 0.025 s [User: 1.786 s, System: 0.303 s] Range (min … max): 2.142 s … 2.227 s 10 runs ``` After: ``` ❯ hyperfine -w 1 -r 10 './pants --no-pantsd list ::' Benchmark #1: ./pants --no-pantsd list :: Time (mean ± σ): 2.193 s ± 0.060 s [User: 1.798 s, System: 0.292 s] Range (min … max): 2.144 s … 2.348 s 10 runs ```
asherf
pushed a commit
that referenced
this pull request
Dec 28, 2021
…and Protobuf (pantsbuild#13981) Because we know that a `SingleSourceField` has exactly one file—and we can ban `*` so can compute its file path without using the engine—we can simplify dependency inference when creating the global module mapping. There's no need to actually look up the file system. A downside of this PR is that we have lazier validation that the `source` field matches files on disk, i.e. that the file is there. But there are still plenty of places this gets validated, such as when computing the dependencies of a target because we have to inspect its source code. (Compared to creating a global module mapping for dep inference in general.) There's a marginal speed up, too: Before: ``` ❯ hyperfine -w 1 -r 25 './pants --no-pantsd dependencies src/python/pants/util/strutil.py:util' Benchmark #1: ./pants --no-pantsd dependencies src/python/pants/util/strutil.py:util Time (mean ± σ): 4.576 s ± 0.139 s [User: 3.180 s, System: 0.657 s] Range (min … max): 4.373 s … 5.003 s 25 runs ``` After: ``` ❯ hyperfine -w 1 -r 25 './pants --no-pantsd dependencies src/python/pants/util/strutil.py:util' Benchmark #1: ./pants --no-pantsd dependencies src/python/pants/util/strutil.py:util Time (mean ± σ): 4.487 s ± 0.172 s [User: 3.019 s, System: 0.628 s] Range (min … max): 4.224 s … 5.094 s 25 runs ``` [ci skip-rust] [ci skip-build-wheels]
asherf
pushed a commit
that referenced
this pull request
May 11, 2023
The Pants native client which was introduced in pantsbuild#11922 has so far only been usable in the Pants repo when the `USE_NATIVE_PANTS` environment variable was set. To make the native client available to end users, this change begins distributing the native-client binary in Pants wheels. A corresponding change in the `scie-pants` repo (pantsbuild/scie-pants#172) uses the native client to run `pants`. To reduce the surface area of `scie-pants` (rather than having it be responsible for handling the special `75` exit code similar to the `pants` script integration), this PR also moves to having the native-client execute its own fallback (via `execv`) to the Pants entrypoint. In future, the `pantsbuild/pants` `pants` script could also use that facility (e.g. by specifying a separate `pants_server` bash script as the entrypoint to use as the `_PANTS_SERVER_EXE`). ---- As originally demonstrated on pantsbuild#11831, the native client is still much faster than the legacy client. Using pantsbuild/scie-pants#172, the timings look like: ``` Benchmark #1: PANTS_NO_NATIVE_CLIENT=true PANTS_SHA=836cceb74e6af042e7c82677f3ceb4927efce20e scie-pants-macos-x86_64 help Time (mean ± σ): 1.161 s ± 0.067 s [User: 830.6 ms, System: 79.2 ms] Range (min … max): 1.054 s … 1.309 s 10 runs Benchmark #2: PANTS_SHA=836cceb74e6af042e7c82677f3ceb4927efce20e scie-pants-macos-x86_64 help Time (mean ± σ): 271.0 ms ± 30.6 ms [User: 8.9 ms, System: 6.9 ms] Range (min … max): 241.5 ms … 360.6 ms 12 runs Summary 'PANTS_SHA=836cceb74e6af042e7c82677f3ceb4927efce20e scie-pants-macos-x86_64 help' ran 4.29 ± 0.54 times faster than 'PANTS_NO_NATIVE_CLIENT=true PANTS_SHA=836cceb74e6af042e7c82677f3ceb4927efce20e scie-pants-macos-x86_64 help' ``` Fixes pantsbuild#11831.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps junit from 4.11 to 4.13.1.
Release notes
Sourced from junit's releases.
Commits
1b683f4[maven-release-plugin] prepare release r4.13.1ce6ce3aDraft 4.13.1 release notesc29dd82Change version to 4.13.1-SNAPSHOT1d17486Add a link to assertThrows in exception testing543905dUse separate line for annotation in Javadoc510e906Add sub headlines to class Javadoc610155bMerge pull request from GHSA-269g-pwp5-87ppb6cfd1eExplicitly wrap float parameter for consistency (#1671)a5d205cFix GitHub link in FAQ (#1672)3a5c6b4Deprecated since jdk9 replacing constructor instance of Double and Float (#1660)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)@dependabot use these labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill set the current milestone as the default for future PRs for this repo and languageYou can disable automated security fix PRs for this repo from the Security Alerts page.