Generally doing a munkiimport on a .app or .pkg to get it into a Munki repository will tend to just work. Munki will automatically create the appropriate .plist file and know whether an app is installed or not based on the receipts or based on an installs array (more details at How Munki Decides What Needs To Be Installed).
Occasionally, you come across a badly-constructed .app or .pkg that Munki doesn’t know what to do with. A great example of this is Oracle’s SQLDeveloper.app, which comes in different versions, but the .app itself has no indication of what version it is. By default, all (recent, anyway, as of this writing) versions of SQL Developer show as version 1.1. So version 184.108.40.206 is 1.1 and version 220.127.116.11.64 is also 1.1. The only way to know the actual version you’re using is knowing what it was when you downloaded it. The .app itself doesn’t contain the version number in any obvious place (in this particular case, it happens to live in SQLDeveloper.app/Contents/Resources/sqldeveloper/bin/version.properties, but how would Munki know to even look there?).
Having every version of the app identify as one version poses a couple of problems. Still with SQL Developer as an example, if you import 18.104.22.168 as 1.1, that’ll work fine, until you want to import 22.214.171.124.64. If you import 126.96.36.199.64 as 1.1 also, Munki won’t know to upgrade clients to the new version. And if you import 188.8.131.52.64 as 184.108.40.206.64, Munki will keep thinking it has to upgrade (the install/upgrade process will keep looping), because it won’t see 220.127.116.11.64 as 18.104.22.168.64—it will see it as 1.1!
So, apart from filing a bug report with the developers and hoping they fix it, there are a couple of workarounds you can use.
Workaround #1: Find a unique part of the .app and hash that
Instead of running the normal
Workaround #2: Manually change the version number
Another approach is just to do what the developers should have done in the first place—go into /Applications/SQLDeveloper.app/Contents/Info.plist, and edit the version there before importing the .app into Munki. So, as an example, for SQL Developer, I changed
Thanks to Greg Neagle for not just developing Munki but also for support on this particular issue via the Munki Discuss mailing list.