-
-
Notifications
You must be signed in to change notification settings - Fork 25.8k
MAINT Remove travis ci config and related doc #25562
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
ec25fe3
ea0162b
f2f71f9
5175a12
46957a0
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
This file was deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this section because it was phrased in a travis specific way (and only focused on a technical detail, cron jobs without explaining the high level purpose) but I think it might be helpful to give a high level description of our CI somewhere in the doc, both for new contributors and maintainers.
In particular, we should summarize the various missions of our CI:
Ideally this doc should only describe the high level objectives of the CI infrastructure and point the readers to the config files and the
build_tools
folder for the details (which typically evolve faster than we update the doc).We should carefully use inline comments in those config files and scripts to make sure that people easily understand how they operate and how to conduct common maintenance operations (e.g. rotating secret tokens).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you see this as something for contributors, for maintainers, for both?
This sounds like a good idea, but at the same time striking the right balance between documenting the general idea and not the minor details is not that easy.
In my experience, CI change quite often and we forget to update the documentation making things untrustable quite quickly ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a unique chapter/section on the CI and cross-link from the contributors and maintainers guides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will open an issue to discuss this in a more visible place.
EDIT: done at #25565.