modifying pruning logic to less aggressively purge files after publish #2953
Conversation
|
I'm not sure if checking in |
|
|
||
| foreach (var path in library.RuntimeAssemblies) | ||
| { | ||
| keep.Add(CombinePath(packagesDir, path)); | ||
| keep.Add(Path.Combine(packagesDir, Path.GetDirectoryName(path))); |
There was a problem hiding this comment.
Instead of collecting files to keep, this collects TFMs. An alternative is to compare the lock files of the original project and the published output. Or some kind of fuzzy best match to figure it out from the TFM of the published lockfile.
| } | ||
| catch | ||
| { | ||
| continue; |
There was a problem hiding this comment.
can this really happen? and if this does can it really be ignored?
|
We shouldn't check in binary files. For testing nupkg we can generate it on the fly. |
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
7 times, most recently
from
7b9f858
to
6ff3e85
Compare
| @@ -33,11 +34,12 @@ public PublishRoot(Runtime.Project project, string outputPath, IServiceProvider | |||
| TargetRuntimesPath = Path.Combine(outputPath, AppRootName, "runtimes"); | |||
| Operations = new PublishOperations(); | |||
| } | |||
|
|
|||
There was a problem hiding this comment.
will remove spacing
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
from
6ff3e85
to
d060c2b
Compare
|
Note that if you publish without restoring, no lock file will be generated for the main project and no pruning will occur. |
| { | ||
| // 'shared' folder is build time dependency, so we only copy it when deploying with source | ||
| specialFolders.Add("shared"); | ||
| return true; |
There was a problem hiding this comment.
Maybe we should remove the return value for PrunePackages. There are no cases for which we want to report a non-successful pruning that stops further publishing progress. If there are problems, such as no lock file in the main project, just don't prune anything.
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
from
cc98ec7
to
02390ff
Compare
|
ping @davidfowl @moozzyk @troydai |
| var specialFolderPath = CombinePath(packagesDir, specialFolder); | ||
| foreach (var target in root.MainProjectLockFile.Targets.Where(projectTarget => | ||
| !root.PublishedLockFile.Targets.Any(publishTarget => | ||
| projectTarget.TargetFramework == publishTarget.TargetFramework))) |
There was a problem hiding this comment.
Only pruning by TFM. Maybe we should prune by RID if one is specified as well?
There was a problem hiding this comment.
Maybe move this into a method.
There was a problem hiding this comment.
Difficult to do lockfile based RID filtering for now since the published project is not restored with the runtimes specified by publish. Could potentially revisit this once publish is refactored to be based on lock file.
|
|
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
2 times, most recently
from
4b094ad
to
dba7778
Compare
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
from
dba7778
to
310ad1d
Compare
|
|
JunTaoLuo
force-pushed
the
johluo/2850-less-aggressive-postpublish-pruning
branch
from
310ad1d
to
1d45291
Compare
#2850