| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 4454fa998c9da1f1eee1602c8e8cd2732505c104.
(cherry picked from commit 395fb701e74f58e6c77e2cbdc1967478924e819f)
|
|
|
|
[CI] Use a lockfile for installing the `datadog` package
Without a lockfile, it could fail to compile when the dependencies have changed. Reported [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/CI.20failure.20in.20DataDog.20upload).
r? `@jdno`
try-job: x86_64-msvc-ext2
|
|
Without a lockfile, it could fail to compile when the dependencies have changed.
|
|
|
|
CI: increase timeout from 4h to 6h
Our CI got a bit slower since the last time we [lowered](https://github.com/rust-lang/rust/pull/127648) the timeout, and if e.g. Docker build cache is broken, the timeout can be triggered.
Discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/ci.20job.20timings.20stats).
|
|
It was renamed to "main" from "master".
|
|
|
|
Our CI got a bit slower since the last time we lowered the timeout, and if e.g. Docker build cache is broken, the timeout can be triggered.
|
|
|
|
|
|
force "HEAD" for non-CI and `git_upstream_merge_base` for CI environment
When rust-lang/rust is configured as remote, some of the git logic (for tracking changed files) that uses get_closest_merge_commit starts to produce annoying results as the upstream branch becomes outdated quickly (since it isn't updated with git pull). We can rely on HEAD for non-CI environments as we specifically treat bors commits as merge commits, which also exist on upstream. As for CI environments, we should use `git_upstream_merge_base` to correctly track modified files as bors commits may be in `HEAD` but not yet on the upstream remote.
This is also an alternative fix for https://github.com/rust-lang/rust/issues/129528 since https://github.com/rust-lang/rust/pull/131331 reverts the previous fix attempts.
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
remove blank issue template
r? `@Noratrieb`
So there are currently two blank issue templates. One called "Blank Issue" and one called "Blank issue". Wildly different, of course. It seems that one is auto generated by GitHub, while the other one has an explicit template for it. This removes the explicit one so there's only one "Blank [iI]ssue" in the list. Unfortunately, the only way to test if it works is merging this and finding out, but it seems obvious that it would work.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #130863 (Relax a debug assertion for dyn principal *equality* in codegen)
- #131016 (Apple: Do not specify an SDK version in `rlib` object files)
- #131140 (Handle `rustc_hir_analysis` cases of `potential_query_instability` lint)
- #131141 (mpmc doctest: make sure main thread waits for child threads)
- #131150 (only query `params_in_repr` if def kind is adt)
- #131151 (Replace zero-width whitespace with a visible `\` in the PR template)
- #131152 (Improve const traits diagnostics for new desugaring)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
[CI] Upload average CPU utilization of CI jobs to DataDog
This PR adds a new CI step that uploads the average CPU utilization of the current GH job to Datadog. I want to add more metrics in follow-up PRs.
r? `@jdno`
try-job: dist-i686-msvc
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-18
|
|
People tried to copy the `r?` which had an invisible zero-width
whitespace, causing rustbot to not recognize the instruction, and which
makes it difficult to figure out why it didn't work.
|
|
|
|
|
|
Before the workspace split, the library was covered by the weekly `cargo
update` cron job. Now that the library has its own workspace, it doesn't
get these updates.
Add `library/Cargo.toml` to the job so updates happen again.
|
|
|
|
|
|
The previous value, 10 hours, is unnecessarily long, since most of our jobs finish within 2.5 hours currently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add pull request template asking for relevant tracking issues
As mentioned at RustNation, I would like to remind PR authors to link to relevant tracking issues when opening PRs as it is otherwise very easy to forget doing so.
There's a certain amount of conflict between making the template as small as possible while still being clear for new contributors. I am very much open to changes here but really want to try this out.
Also unsure how much formal buy-in we need here. Maybe merge this pinging t-compiler and t-libs, and then ask how people feel about this on zulip in a few weeks?
r? `@davidtwco`
|
|
|
|
use key-value format in stage0 file
Currently, we are working on the python removal task on bootstrap. Which means we have to extract some data from the stage0 file using shell scripts. However, parsing values from the stage0.json file is painful because shell scripts don't have a built-in way to parse json files.
This change simplifies the stage0 file format to key-value pairs, which makes it easily readable from any environment.
See the zulip thread for more details: https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/Using.20different.20format.20in.20the.20stage0.20file
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Neither `env.DEPLOY` nor `env.DEPLOY_ALT` should be present in this job.
|
|
|
|
|
|
CI: implement job skipping in Python matrix calculation
This removes the `step` YAML anchor and the corresponding bash script.
Best reviewed commit-by-commit.
r? ```@pietroalbini```
|
|
|
