New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add burn support for only caching packages #213

Merged
merged 8 commits into from Jun 7, 2015

Conversation

Projects
None yet
5 participants
@heaths
Contributor

heaths commented Feb 28, 2015

Rebased and squashed on top of the current develop HEAD. This does not include the async install as there was some debate about it and we do not think we'll need it going forward anyway.

@barnson

This comment has been minimized.

Show comment
Hide comment
@barnson

barnson Mar 1, 2015

Member

Let's talk about this at Tuesday's meeting. We'd talked about making this something the BA could tell the engine to do rather than making it an all-engine job.

Member

barnson commented Mar 1, 2015

Let's talk about this at Tuesday's meeting. We'd talked about making this something the BA could tell the engine to do rather than making it an all-engine job.

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Mar 1, 2015

Contributor

My $0.02 in case I can't make triage: take this into wix3 as-is. Any changes to the BA will likely require an interface change which I know @robmen is rethinking for wix4.

Contributor

heaths commented Mar 1, 2015

My $0.02 in case I can't make triage: take this into wix3 as-is. Any changes to the BA will likely require an interface change which I know @robmen is rethinking for wix4.

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Mar 4, 2015

Contributor

If this looks good, I'll make the same changes for the wix4 branch. @rseanhall , please have a look as well since I know you have a related PR.

Contributor

heaths commented Mar 4, 2015

If this looks good, I'll make the same changes for the wix4 branch. @rseanhall , please have a look as well since I know you have a related PR.

@heaths

This comment has been minimized.

Show comment
Hide comment
@heaths

heaths Mar 12, 2015

Contributor

Since you took @rseanhall's implementation, is there any point in this PR now? I don't understand what he was getting at since he was claiming there was a bug in something that Burn didn't seem to support (which was waiting on the original PR that included async).

Contributor

heaths commented Mar 12, 2015

Since you took @rseanhall's implementation, is there any point in this PR now? I don't understand what he was getting at since he was claiming there was a bug in something that Burn didn't seem to support (which was waiting on the original PR that included async).

heaths added some commits May 9, 2015

Merge branch 'develop' into issue4432
Conflicts:
	History.md
	src/burn/engine/plan.cpp
Support cache-only mode in Burn via BA
Resolves issue #4432 by adding a BOOTSTRAPPER_ACTION_CACHE mode that BAs can set (i.e. Burn does not directly
support setting via command line) and will plan to cache all package types by default.

WixStdBA was updated to support this mode if opted in via a new @SupportCacheOnly attribute.
@@ -1033,6 +1037,9 @@ extern "C" HRESULT PlanCachePackage(
if (fBARequestedCache || NeedsCache(pPlan, pPackage))
{
// The behavior for cache only mode is to do nothing on rollback, e.g. for subsequent install on demand scenarios.

This comment has been minimized.

@rseanhall

rseanhall May 19, 2015

Member

Doesn't this make it possible for packages to be in the cache without the bundle available to clean it out?

@rseanhall

rseanhall May 19, 2015

Member

Doesn't this make it possible for packages to be in the cache without the bundle available to clean it out?

This comment has been minimized.

@heaths

heaths May 25, 2015

Contributor

It's possible, yes, but part of the point. When we introduced this feature, it was to pre-cache the Windows Phone emulator (in the background, hence async originally coming in with this feature) so it's available when you want it later but may not be online. A bundle can still remove the cache even if its not installed, though.

@heaths

heaths May 25, 2015

Contributor

It's possible, yes, but part of the point. When we introduced this feature, it was to pre-cache the Windows Phone emulator (in the background, hence async originally coming in with this feature) so it's available when you want it later but may not be online. A bundle can still remove the cache even if its not installed, though.

This comment has been minimized.

@rseanhall

rseanhall May 25, 2015

Member

A bundle can remove the cache if it's not installed, but the user can't run the bundle unless it's available somewhere. It's not very user friendly for a package to be put in the package cache without also ensuring its owning bundle is also in the cache.

@rseanhall

rseanhall May 25, 2015

Member

A bundle can remove the cache if it's not installed, but the user can't run the bundle unless it's available somewhere. It's not very user friendly for a package to be put in the package cache without also ensuring its owning bundle is also in the cache.

This comment has been minimized.

@heaths

heaths May 25, 2015

Contributor

Just about to update the PR. I'd recommend, if you want to discuss further, we bring it up at the next triage and file it as a feature bug. This needs to get checked in and merging grows difficult.

Besides, the bundle gets cached as well so it is somewhere.

@heaths

heaths May 25, 2015

Contributor

Just about to update the PR. I'd recommend, if you want to discuss further, we bring it up at the next triage and file it as a feature bug. This needs to get checked in and merging grows difficult.

Besides, the bundle gets cached as well so it is somewhere.

ExitOnFailure(hr, "Failed to append rollback cache action.");
// Only plan the cache rollback if the package is also going to be uninstalled;
// otherwise, future operations like repair will not be able to locate the cached package.
BOOL fPlanCacheRollback = (BOOTSTRAPPER_ACTION_STATE_UNINSTALL == pPackage->rollback);

This comment has been minimized.

@rseanhall

rseanhall May 19, 2015

Member

Doesn't this make it possible for packages to be in the cache without the bundle available to clean it out?

@rseanhall

rseanhall May 19, 2015

Member

Doesn't this make it possible for packages to be in the cache without the bundle available to clean it out?

heaths added some commits May 25, 2015

Merge branch 'develop' into issue4432
Conflicts:
	History.md
	src/ext/BalExtension/wixext/BalCompiler.cs
	src/ext/BalExtension/wixext/Xsd/bal.xsd
	src/ext/BalExtension/wixext/data/tables.xml
	src/ext/BalExtension/wixstdba/WixStandardBootstrapperApplication.cpp
@rseanhall

This comment has been minimized.

Show comment
Hide comment
@rseanhall

rseanhall May 26, 2015

Member

This looks like it's ready to merge (except for the History.md changes that are easily fixed). I'll have to test out the failure scenario and see what get left behind in the cache.

Member

rseanhall commented May 26, 2015

This looks like it's ready to merge (except for the History.md changes that are easily fixed). I'll have to test out the failure scenario and see what get left behind in the cache.

barnson added a commit that referenced this pull request Jun 7, 2015

Merge pull request #213 from heaths/issue4432
Add burn support for only caching packages

@barnson barnson merged commit e0afc83 into wixtoolset:develop Jun 7, 2015

@heaths heaths deleted the heaths:issue4432 branch Jun 7, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment