Comments (5)
cc @aidanhs
from rust-central-station.
clients that are now broken.
Also rustup - https://github.com/rust-lang-nursery/rustup.rs/blob/a11c01e8c07f02a189c2d1c824b968bc2a935036/appveyor.yml#L37
Delete the rust-lang-ci bucket
Hmm. This will also break the ability to build some old versions of Rust yourself. I think it's at least worth doing the thought experiment to consider leaving that bucket stagnant but still available. Maybe if hosting old builds in two places is excessively expensive, we just don't copy them across? Not sure what the best approach is.
Edit: then again, when we were using the centos 5 packages and they went away, that broke our ability to build older versions of rust with the docker images - maybe it's not a big deal.
If we do decide to delete part/all, I'd like to at least propose a deprecation period (say 1 stable release?) where we announce on irlo/reddit/wherever so packagers (or other people) using artifacts can move over. Note I'm just suggesting this out of courtesy - the artifacts are in a bucket called rust-lang-ci, so projects not under the rust-lang umbrella shouldn't expect them to always be available :)
from rust-central-station.
Yeah I don't think we can really provide a guarantee that our CI infrastructure always works, no only with centos 5 going away but other things like eventually ubuntu 16.04 will be out of date etc. I think the important part is checking out the repo and getting the same source, but building is sort of left up to the user.
And yeah I assumed we were going to delete for cost reasons, the rust-lang-ci bucket isn't exactly small... Although this may also be a great point to set forth a policy about deletion of old artifacts. Our "ever growing" bucket is static.rust-lang.org, and I think we'd rather not have two. How about:
- Don't delete rust-lang-ci for 30 days (or 2 cycles)
- rust-lang-ci2 policy is:
rust-ci-mirror
is permanentcargo-builds
is getting entirely deleted (no one should use this any more)rustc-builds-try
- deleted after 30 daysrustc-builds-alt
- not sure what to do here. If servo updates at least once every 30 days we could delete 30 day old builds. Depend on what they do.rustc-builds
- maybe deleted after 90 days?
from rust-central-station.
I wasn't able to find any previous discussion on the deletion policy issue. My main issue concerns bisecting past regressions, and I think deletion of stuff from rustc-builds
after 90 days is a bit too short. There is definitely interest in regressions from more than 90 days ago... See this bug for example.
I think the limit should be raised to 6 months, that is 180 days, or maybe even a year. Regarding size concerns: we could adopt courgette which operates on diffs. E.g. only each "nightly build" would be stored completely, and the following builds would be stored as diffs from that build. Of course one has to implement this first but I think with this change one can achieve a quite remarkable decrease in required storage space, that can allow us to store the fine builds for a much longer time than 90 days.
from rust-central-station.
I believe this is all done now, so closing.
from rust-central-station.
Related Issues (17)
- Tracking issue: Rustbuild submodule management can break nightlies HOT 2
- bors/homu should set S- tags HOT 1
- Test generated manifests against rustup HOT 1
- Promotion should use a consistent date and time HOT 3
- Letsencrypt is broken in a long-running RCS container, and can only be fixed by chance HOT 1
- run-prod.sh is wrong HOT 1
- Logs on central station are still inconsistent HOT 2
- Option to rollback to the previous release HOT 1
- Dependabot can't resolve your Rust dependency files
- Directory listing generation should be faster HOT 2
- Mailing list synchronization broken
- robots.txt is not being updated HOT 4
- Add ability to roll back a nightly rust release HOT 1
- Gate rustc on both Azure and (GitHub Actions - macOS) HOT 2
- Add license to rust-central-station HOT 14
- Make nagbot filter on S- tags HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust-central-station.