Delay the creation of the context used when a package failed to build up until the package failed - #6278
Delay the creation of the context used when a package failed to build up until the package failed#6278kit-ty-kate wants to merge 2 commits into
Conversation
33d9210 to
c0bcb68
Compare
rjbou
left a comment
rjbou
left a comment
There was a problem hiding this comment.
The PR contains 2 things: the delay of context creation for package build, and the delay of metadata processes as the sumary is not always printed. PR title is good, but main comment and master changes should contains both. Ideally, 2 commits if it can be easily split.
Otherwise, lgtm!
… up until the package failed
c0bcb68 to
c73333f
Compare
kit-ty-kate
left a comment
kit-ty-kate
left a comment
There was a problem hiding this comment.
The PR contains 2 things: the delay of context creation for package build, and the delay of metadata processes as the sumary is not always printed. PR title is good, but main comment and master changes should contains both. Ideally, 2 commits if it can be easily split.
I don't think those are two separate things. cmd_metadata, p_metadata and r_info are all storing the same things only in three different types. If anything i should be talking about metadata instead of context
| let info = | ||
| make_info ~cmd ~args ~cwd ~env_file ~stdout_file ~stderr_file ~metadata () in | ||
| make_info ~cmd ~args ~cwd ~env_file ~stdout_file ~stderr_file | ||
| ~metadata:(Lazy.force metadata) () |
There was a problem hiding this comment.
this is forced too early. I think there is a way to run it only when the process finished
2 participants
Noticed while reviewing #6274.
It turns out that we try to fetch the revision of each packages being built even before executing the command, but that information is only used in rare cases so if many git packages are used this can cause some wasted time (not too much, up to a couple seconds on slow hardware with large installs, but not nothing)