Policy to install from dmg

It would be nice actually if we could use vendor DMGs as is without any special scripts or modification in Jamf Pro. I believe Munki works this way, as in if you use a vendor DMG that has an app at the top level of the mounted disk image, it just knows that that app should get copied to the /Applications/ folder, unless otherwise specified.
But Jamf doesn't do this as you already know.

I believe there are some scripts out there that will do this for you written by members of the community. As in, you can push the dmg as "cache" instead of "install" and it locates the cached DMG, mounts it silently, and copies the app bundle to Applications, or runs the .pkg if there's one of those instead.
I can't find that script at the moment, but I feel like maybe @rtrouton wrote one maybe? I could be wrong. Might have been someone else.

What I do know is there are a few simple applications out there that can take a DMG as a dropped file or source file and automatically create a valid .pkg installer that will install the app bundle from the DMG into Applications. I have one here, but I have not updated it in several years now and I'm not 100% sure if it still works in current OSes. I'll have to test it to see, and will work on an update if needed.
I know Rich also has one he built that does basically the same thing. You might want to try one of those, that way you can easily build PKG installers from anything that comes in that format, which is probably more reliable than using a DMG and post processing script.

Why can't you just use Composer to create a PKG? Chrome and Firefox both install as a drag and drop. Once these apps are dragged into the Applications folder, and opened a couple of times to get past the initial verification prompt that all downloaded apps trigger, they can be dragged into Composer so that you can create a PKG from them. The app you're talking about should work the sam way as long as there's no other process that needs to run from this DMG.

I'm a firm believer in not re-inventing the wheel. For many apps the work of packaging or installing has already been done...

If you want to control what version of an app is being deployed as a .pkg via Jamf Pro, go and see if there's already an AutoPkg recipe for the software (AutoPkgr provides an optional GUI). If there's no existing recipe, create one and share it with the AutoPkg community.

If running a script to install from a whatever's current on the vendor's site is acceptable, take a look at Installomator. If the app you want is missing, add it and share.

I usually use composer or packages but just wanted to see if there was a JAMF option that would just put the app in /applications using the vendors dmg

For those looking to simplify packaging something here's a tool that Twocanoes created: https://bitbucket.org/twocanoes/repackage/src/master/

@tcandela The problem is that there is no standard that relates the name of the dmg to the name of the app. So jamf can not know which folder inside the dmg should be copied to the Applications folder. We started with a script that worked when the names of dmg, volume and app folder where identical. We then needed to extend that to cover the case that any of the names differ.

I very much prefer to build a package, even for simple cases where I can just drag the app to the Applications folder. For me DMGs are no proper way of installing a product.

For a vast majority of the cases copying *.app to /Applications would eliminate the repackaging burden. It's not like Jamf couldn't implement

VOLUME=$(hdiutil attach -nobrowse '[DMG FILE]' |
    awk 'END {print $3}'; exit ${PIPESTATUS[0]}) &&
(rsync -a "$VOLUME"/*.app /Applications/; SYNCED=$?
    hdiutil detach -quiet "$VOLUME"; exit $? || exit "$SYNCED")

We are talking about a single feature that would stream line deployment for a huge number of folks.
I could not find a feature request so I created Allow DMG installers to copy *.app to /Applications
Vote it up and spread the word!

VOLUME=$(hdiutil attach -nobrowse '[DMG FILE]' |
    awk 'END {print $3}'; exit ${PIPESTATUS[0]}) &&
(rsync -a "$VOLUME"/*.app /Applications/; SYNCED=$?
    hdiutil detach -quiet "$VOLUME"; exit $? || exit "$SYNCED")

Tempted to just make this a script for now.  Cache the .dmg then have the script dynamically handle the rest.

VOLUME=$(hdiutil attach -nobrowse '[DMG FILE]' |
    awk 'END {print $3}'; exit ${PIPESTATUS[0]}) &&
(rsync -a "$VOLUME"/*.app /Applications/; SYNCED=$?
    hdiutil detach -quiet "$VOLUME"; exit $? || exit "$SYNCED")

Here's what I came up with.  It's not perfect.  I'm not sure how to handle the extra hidden characters yet when pulling in the volume location (when it has spaces), so I am using bash and just re-exporting the variable from echo for now which seems to work.  The dmg file and app name you want to copy are put in params 4 and 5:

Thanks @AdAsterix! 

I have not used awk that much before and searched up documentation on it. Still not sure what this line is doing: 

```

awk 'END {$1=$2="";print $0}'; exit ${PIPESTATUS[0]})

```

If you are feeling open to it, would you mind putting that into words?

Either way, this script worked for me after some fiddling around. I found I had to set the Package payload to "Cache" the DMG instead of "Install". That may be common knowledge for others but just wanted to mention it.

Also, I was trying to put in a \\ character to account for spaces in the App name after reading your concern about spaces but realized that was throwing errors because the parameter was being pulled in as a string and did not require the \\ character. Again, may be common knowledge but just adding it here as well.

Thanks, again!