do_cmake.sh: print progress while updating submodules#65303
do_cmake.sh: print progress while updating submodules#65303rishabh-d-dave wants to merge 1 commit intoceph:mainfrom
Conversation
Signed-off-by: Rishabh Dave <ridave@redhat.com>
|
jenkins test make check |
|
jenkins test api |
|
jenkins test api |
2 similar comments
|
jenkins test api |
|
jenkins test api |
|
jenkins test api |
2 similar comments
|
jenkins test api |
|
jenkins test api |
|
why? |
so that we can see progress when submodules are being cloned/updates. this is especially useful when submodule is huge or when network is a bit flaky. Looking at 63171, perhaps we can add an extra flag that allows us to choose whether we want to see progress. |
|
|
||
| if [ -d .git ]; then | ||
| git submodule update --init --recursive --recommend-shallow | ||
| git submodule update --init --recursive --recommend-shallow --progress |
There was a problem hiding this comment.
| git submodule update --init --recursive --recommend-shallow --progress | |
| EXTRA=() | |
| if [ -t 1 ] ; then | |
| EXTRA+=('--progress') | |
| fi | |
| git submodule update --init --recursive --recommend-shallow "${EXTRA[@]}" |
would probably address @dmick 's concerns.
There was a problem hiding this comment.
would probably address @dmick 's concerns.
I don't even wanna see that in an interactive run personally, but if others really do, we could add a -v switch
|
just my 2 cents, though not especially constructive: this script has been serving two different use cases for quite a while: developers use it for local build setup, and ci uses it for make check. this pr is a great example of how those use cases differ i would recommend that developers just use the git/cmake tools directly instead of relying on a helper script. you know these tools and can be opinionated about their options/configuration. Sage created this script at a time when the cmake port was relatively new and the team was still unfamiliar with it, but surely that has changed in the decade since the problem with serving multiple use cases is that we have to make the script more complicated than either actually warrants |
|
I would, and have with my removal, argue that "seeing progress" is not useful in any context. If you so strongly disagree then I'd support an extra argument to do_cmake (or just keep a personal patch around for the one time a year it gets changed and you have to update it). Blathering percentages to the screen helps no one. |
|
Personally I am looking into removing this from |
|
closed as rejected. |
Contribution Guidelines
To sign and title your commits, please refer to Submitting Patches to Ceph.
If you are submitting a fix for a stable branch (e.g. "quincy"), please refer to Submitting Patches to Ceph - Backports for the proper workflow.
When filling out the below checklist, you may click boxes directly in the GitHub web UI. When entering or editing the entire PR message in the GitHub web UI editor, you may also select a checklist item by adding an
xbetween the brackets:[x]. Spaces and capitalization matter when checking off items this way.Checklist
Show available Jenkins commands
jenkins test classic perfJenkins Job | Jenkins Job Definitionjenkins test crimson perfJenkins Job | Jenkins Job Definitionjenkins test signedJenkins Job | Jenkins Job Definitionjenkins test make checkJenkins Job | Jenkins Job Definitionjenkins test make check arm64Jenkins Job | Jenkins Job Definitionjenkins test submodulesJenkins Job | Jenkins Job Definitionjenkins test dashboardJenkins Job | Jenkins Job Definitionjenkins test dashboard cephadmJenkins Job | Jenkins Job Definitionjenkins test apiJenkins Job | Jenkins Job Definitionjenkins test docsReadTheDocs | Github Workflow Definitionjenkins test ceph-volume allJenkins Jobs | Jenkins Jobs Definitionjenkins test windowsJenkins Job | Jenkins Job Definitionjenkins test rook e2eJenkins Job | Jenkins Job Definition