Verbose Go Mod Status

[HenrySkup]

Could we get a verbose readout while Go Mods / Hugo Mods are fetched? This can take a while, and having some sort of visibility of what's happening would make the UX/UI better.

[HenrySkup]

🙏

[bep]

In #6520 I have added some timer output if collecting modules takes "some time". While testing it, I do see that Go prints when it downloading modules. Are you not currently seeing the "go: finding ..." statements?

And yes, I do find it curious that the "Total in ..." is less than "Collected modules ...", but that's because the module collection happens in the init phase and not during the build. I will try to fix that so it looks more "honest". But the below also shows that once cached, the module collection takes no time.

▶ hugo mod clean && hugo --ignoreVendor
go: finding github.com/gohugoio/gohugoioTheme v0.0.0-20191021162625-2e7250ca437d
Collected modules in 3683 ms

                   | EN  | ZH
+------------------+-----+-----+
  Pages            | 471 |  21
  Paginator pages  |   2 |   1
  Non-page files   |  55 |   0
  Static files     | 145 | 145
  Processed images |  99 |   0
  Aliases          |  16 |   4
  Sitemaps         |   2 |   1
  Cleaned          |   0 |   0

Total in 2687 ms

go/gohugoio/hugoDocs  security-model ✔                                                                           28m
▶ hugo

                   | EN  | ZH
+------------------+-----+-----+
  Pages            | 471 |  21
  Paginator pages  |   2 |   1
  Non-page files   |  55 |   0
  Static files     | 145 | 145
  Processed images |  99 |   0
  Aliases          |  16 |   4
  Sitemaps         |   2 |   1
  Cleaned          |   0 |   0

Total in 2267 ms

[bep]

The same output from a more modular site:

sites/hugomod/my-modular-site  master ✗                                                                       98d ⚑
▶ hugo
go: finding github.com/bep/hugo-fresh v1.0.1
go: finding github.com/bep/hugo-github/repo v0.0.0-20191002153307-6ef93234ce20
go: finding github.com/bep/hugotestmods/myassets v1.0.4
go: finding github.com/bep/hugotestmods/mymounts v1.2.0
go: finding github.com/bep/hugotestmods/mypartials v1.0.7
go: finding github.com/bep/hugotestmods/myv2 v1.0.0
go: finding github.com/spf13/hyde v1.0.1
hugo: collected modules in 8350 ms

                   | EN
+------------------+----+
  Pages            |  5
  Paginator pages  |  0
  Non-page files   |  0
  Static files     | 46
  Processed images |  3
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Total in 8429 ms

sites/hugomod/my-modular-site  master ✗                                                                       98d ⚑
▶ hugo

                   | EN
+------------------+----+
  Pages            |  5
  Paginator pages  |  0
  Non-page files   |  0
  Static files     | 46
  Processed images |  4
  Aliases          |  0
  Sitemaps         |  1
  Cleaned          |  0

Total in 192 ms

Second build is with "warm cache".

[bep]

I'm merging the above PR. If it still isn't good enough, please shout.

[HenrySkup]

Looks good. I've found that there is a long delay between running the build and when go: finding... prints to screen (and when it does, it does so for all mods at one time).

Maybe having a finding => found => pulling => done sequence would help with debug?

(I also hope that I'm doing my cacheing correctly.)

[bep]

Maybe having a finding => found => pulling => done sequence would help with debug?

I kind of dislike to fill my screen with lots of lines for every build if I don't have to and since this is delegated to Go and there is no more verbose output to have there (I checked), the best thing we could add is a "Start collecting ..." which we can add, but just as a INFO statement.

When I test this with a site with 8-10 modules, I get like 9 seconds the first time (clean cache), then 20-milliseconds or so for the subsequent builds. If you see something else, you should check your cache setup (and do not run with --ignoreCache).

Cache is good.

[bep]

I will take one more stab at this.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.