Closed grahampugh closed 3 years ago
This is an interesting idea, and seems beneficial on first glance. Are there any instances where new_package_request
might be False, but we still want to proceed? I'm thinking of recipes that download a flat package directly from the software developer instead of building a package.
Yes, that's right. I grabbed the following directly from https://github.com/autopkg/jazzace-recipes/blob/master/Template.ds.recipe and it is just as relevant here:
<dict>
<key>Processor</key>
<string>StopProcessingIf</string>
<key>Arguments</key>
<dict>
<key>predicate</key>
<!-- Depending on the processor in the parent recipe, either download_changed (returned by URLDownloader)
or new_package_request (returned by PkgCreator and AppPkgCreator) will be used to the left of the ==. -->
<string>new_package_request == FALSE</string>
</dict>
</dict>
I built in a change to JSSImporter some time ago which negates the need for this (STOP_IF_NO_JSS_UPLOAD
), so I'll close this.
I noticed that no recipes have the
StopProcessingIf
process in them. If upstream.pkg
recipes do not have this inside them (which seems to be the case sometimes, e.g. Carbon Copy Cloner), thenJSSImporter
will proceed every time.JSSImporter
creates a "Testing" policy. A normal mode of operation would be to promote/stage/delete that policy after testing. But withoutStopProcessingIf
, the policy will be re-created after every AutoPkg run, regardless of whether there is an update to the package.To prevent this, I'm having to create my own .jss recipes for every software title, with
StopProcessingIf
added, like so:I may be missing something, but if not, could we add a requirement for .jss recipes to have the
StopProcessingIf
process in them?