search

cms-sw / SCRAM

Software Configuration And Management - CMS internal build tool
Other
10 stars 8 forks source link

Reduce verbosity for `ProjectRename` #56

Closed clelange closed 1 year ago

clelange commented 1 year ago

I'm currently working on some recommendations for analysts who'd like to use CMSSW in their code tests and build software containers. For that, one of the options after testing and compiling in CI is to run scram b ProjectRename after having moved the code area elsewhere. When doing this, SCRAM seems to print out more than 2,000 lines of checks, see e.g. https://gitlab.cern.ch/clange/cmssw-cvmfs-kaniko-2/-/jobs/32457874

Would it be possible to have a significantly reduced printout, e.g. only print out issues instead of printing all successful checks by default and then possibly add a verbose option? Or add a no-verbose option?

cmsbuild commented 1 year ago

A new Issue was created by @clelange Clemens Lange.

@Dr15Jones, @rappoccio, @smuzaffar, @makortel, @sextonkennedy, @antoniovilela can you please review it and eventually sign/assign? Thanks.

cms-bot commands are listed here

smuzaffar commented 1 year ago

@clelange , normally scram should only print something like [a]. From the log you shared, I see scram is setting up all the tools again, this can happen when during the copy the timestamp of the toolfiles in cmssw/config/$SCRAM_ARCH/tools/selected are changed. If you just tar/zip the cmssw area and untar it then scram should already print minimal output

[a]

[muzaffar@cmsdev30 CMSSW_10_6_35]$ scram b projectrename
Reading cached build data
Done: projectrename
clelange commented 1 year ago

Thanks for the prompt reaction @smuzaffar -- I'll have a look if the timestamp changes. Searching around the web, this indeed seems to be an issue and the idea of tarring the area might do the trick. I'll give it a try.

clelange commented 1 year ago

That did the trick: https://gitlab.cern.ch/clange/cmssw-cvmfs-kaniko-2/-/jobs/32484068 It makes the CI code a bit uglier, since one has to tar, but I guess there's not much one can do. Unless there's a SCRAM option to not run all these tool setup steps again (or as initially suggested make them "quiet")?

smuzaffar commented 1 year ago

@clelange , all you need is to make sure that timestamp of tool files are not changed so either use tar/zip or rsync. Making scram to not complain and do the printouts will hide the fact that scram unnecessarily setup all tools (which can sometime take couple of minutes).