allow project configuration to skip packagers

[jmartin-tech]

Description

Since windows builds now offer multiple packagers to execute, allow the project configuration to skip a packager if the maintainer does not want to build that package type.

In original APPX support PR #675, there was mention of discussion on how to supporting multiple package type for a single platform being addressed during rollout, since I don't see another existing option, this is my proposal on how to add user input to determine which package types are desired.

usage in a project DSL to omit APPX build:

package :appx do
  skip_packager true
end

---

Maintainers

Please ensure that you check for:

• If this change impacts git cache validity, it bumps the git cache
  serial number
• If this change impacts compatibility with omnibus-software, the
  corresponding change is reviewed and there is a release plan
• If this change impacts compatibility with the omnibus cookbook, the
  corresponding change is reviewed and there is a release plan

[robbkidd]

I'm not qualified yet to comment on adding this feature, but I can suggest a correction to the error the input validation raises.

[tyler-ball]

One comment but otherwise this LGTM

[tyler-ball]

I would propose we change the signature of this method to be def skip_packager(). IMO if the user is adding skip_packager to their packaging definition that is enough indication of what they want to do. The true or false does not seem necessary

[jmartin-tech]

I like the idea, however there are other options exposed on msi packagers that I based this on.

git grep "def.*\(val = false\)"
lib/omnibus/packagers/msi.rb:    def bundle_msi(val = false)
lib/omnibus/packagers/msi.rb:    def fast_msi(val = false)

I believe consistency is key to adoption of function. I offered another similar option in #842 and master currently offers the above two instances.

If a refactor is desired can I consolidate my 2 PRs and expand to refactor the other two instances which would make this a breaking api change, or this and #843 can land as is, then offer a refactor PR that includes the required version bump.

[jmartin-tech]

This seems to have gotten a number of approvals, can someone take a look here and at #842 to see if we can get these merged?

[jmartin-tech]

Checking in again to see about getting this and #842 into a release.

[marcparadise]

Sorry this has taken so long, thanks for being patient with us. I'm working on getting this merged today.

[marcparadise]

@jmartin-r7 would you be able to rebase this on master? If I do it locally, I'll have to make a new branch and replace the PR.

[jmartin-tech]

I can rebase, there are no conflicts upstream as yet, will hold an hour or so encase would rather avoid need to get approvals again.

[marcparadise]

@jmartin-r7 #875 will be merging shortly, then it will be safe to rebase. It fixes the CI errors you'll otherwise get after a rebase on current master.