CI: fix toolstate publishing #125145
CI: fix toolstate publishing #125145
Conversation
|
rustbot has assigned @Mark-Simulacrum. Use |
rustbot
added
A-testsuite
|
It's pretty impressive that toolstate has presumably been passing for years without a single failure |
|
This was broken by my large CI restructuring that was finished ~2 weeks ago. |
|
Ah! That makes more sense. |
|
@bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (84b9b6d): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (primary -0.9%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 668.459s -> 669.294s (0.12%) |
|
@Kobzol Toolstate publishing seems to be broken since this PR. From https://github.com/rust-lang-nursery/rust-toolstate/commits/master/ there are no commits since before this PR landed. Is this something you can look into? |
|
I am trying to make sense of toolstate publishing, and now I wonder if it has even working before. https://github.com/rust-lang-nursery/rust-toolstate/blob/master/_data/latest.json shouldn't this file be updated when anything changes? It seems like it hasn't been updated for two years. There are various comments in bootstrap code and the Python/Bash script that claim that |
|
I believe the |
|
The |
|
It looks like this broke two years ago then. If you take a look at the history (https://github.com/rust-lang-nursery/rust-toolstate/commits/master/_data/latest.json), there were updates from time to time (every few days), but then it just stopped. |
|
There were frequent updates because miri frequently broke. Then miri was switched to a subtree and removed from the toolstate system. That left just the books, which don't break very often. |
|
I wonder if it's even worth it to keep this if it breaks once every two years 😆 Maybe we should just switch everything to subtrees. Anyway, it looks like the issue is with updating the history, not |
Why does it seem that way? #124050 should have switched the |
|
Yeah, that's what I meant. This PR fixed (hopefully) updating of latest.json, but in the process broke updating of the history, which in turn broke updating of latest.json :) I'll send a PR with a fix soon. |
CI: fix publishing of toolstate history Hopefully fixes the upload of toolstate history that I broke in rust-lang#125145. The problem is that the toolstate environment variables need to be available not just when updating `latest.json` through the Bash/Python script, but also in the main CI workflow, where `history` is updated in bootstrap (the toolstate logic is distributed in two places :/ ). The only tricky thing is how to pass the token secret to the CI job, as I need to enable it only for privileged (`auto`/`try`) builds. I assume that the secret is filled only on `rust-lang-ci`, not on `rust-lang`, so I chose the easiest way of just configuring the environment variable globally. We'll see if that works on PR CI. r? `@ehuss`
Rollup merge of rust-lang#126033 - Kobzol:fix-toolstate-history, r=ehuss CI: fix publishing of toolstate history Hopefully fixes the upload of toolstate history that I broke in rust-lang#125145. The problem is that the toolstate environment variables need to be available not just when updating `latest.json` through the Bash/Python script, but also in the main CI workflow, where `history` is updated in bootstrap (the toolstate logic is distributed in two places :/ ). The only tricky thing is how to pass the token secret to the CI job, as I need to enable it only for privileged (`auto`/`try`) builds. I assume that the secret is filled only on `rust-lang-ci`, not on `rust-lang`, so I chose the easiest way of just configuring the environment variable globally. We'll see if that works on PR CI. r? `@ehuss`
CI: fix publishing of toolstate history Hopefully fixes the upload of toolstate history that I broke in rust-lang/rust#125145. The problem is that the toolstate environment variables need to be available not just when updating `latest.json` through the Bash/Python script, but also in the main CI workflow, where `history` is updated in bootstrap (the toolstate logic is distributed in two places :/ ). The only tricky thing is how to pass the token secret to the CI job, as I need to enable it only for privileged (`auto`/`try`) builds. I assume that the secret is filled only on `rust-lang-ci`, not on `rust-lang`, so I chose the easiest way of just configuring the environment variable globally. We'll see if that works on PR CI. r? `@ehuss`
CI: fix publishing of toolstate history Hopefully fixes the upload of toolstate history that I broke in rust-lang/rust#125145. The problem is that the toolstate environment variables need to be available not just when updating `latest.json` through the Bash/Python script, but also in the main CI workflow, where `history` is updated in bootstrap (the toolstate logic is distributed in two places :/ ). The only tricky thing is how to pass the token secret to the CI job, as I need to enable it only for privileged (`auto`/`try`) builds. I assume that the secret is filled only on `rust-lang-ci`, not on `rust-lang`, so I chose the easiest way of just configuring the environment variable globally. We'll see if that works on PR CI. r? `@ehuss`
Toolstate publishing after something broke was not working (discovered here). The toolstate env. vars should only be needed for the publishing step, so I moved them there.
The toolstate script is also being checked in
mingw-checkon PR and auto CI, but it doesn't really seem to do anything, and it shouldn't require the token.