What's missing
PoliciesService.PushRevision lists the server's cookbook artifacts and uploads only the identifiers it lacks (a 409 from a concurrent pusher counts as already uploaded). That is the right behaviour, and it matches chef-cli. But the caller cannot tell which artifacts were uploaded: it returns only the stored *PolicyRevision.
cinc-cli's cinc policy push reports how many cookbooks a push uploaded. Without this information it reported every cookbook as uploaded, even on a second push of the same lock that uploaded nothing. The CLI now lists /cookbook_artifacts itself before calling PushRevision to work out the count, which means a second listing of every artifact in the org on each push, and a count that can be off if another push lands in between.
Suggestion
Have the push report what it did, for example:
type PushResult struct {
Revision *PolicyRevision
Uploaded []string // cookbook-lock names whose artifacts this call uploaded
Existing []string // already on the server (listed, or a 409 on upload)
}This could be a new PushRevisionWithResult (or an options/variadic form) so the existing signature keeps working.
How it was found
The cinc-cli integration suite case policies/push-again-uploads-nothing pushes one lock to two policy groups and checks the second push reports zero uploads. The CLI-side workaround is cinc-project/cinc-cli#219.
What's missing
PoliciesService.PushRevisionlists the server's cookbook artifacts and uploads only the identifiers it lacks (a 409 from a concurrent pusher counts as already uploaded). That is the right behaviour, and it matches chef-cli. But the caller cannot tell which artifacts were uploaded: it returns only the stored*PolicyRevision.cinc-cli's
cinc policy pushreports how many cookbooks a push uploaded. Without this information it reported every cookbook as uploaded, even on a second push of the same lock that uploaded nothing. The CLI now lists/cookbook_artifactsitself before callingPushRevisionto work out the count, which means a second listing of every artifact in the org on each push, and a count that can be off if another push lands in between.Suggestion
Have the push report what it did, for example:
This could be a new
PushRevisionWithResult(or an options/variadic form) so the existing signature keeps working.How it was found
The cinc-cli integration suite case
policies/push-again-uploads-nothingpushes one lock to two policy groups and checks the second push reports zero uploads. The CLI-side workaround is cinc-project/cinc-cli#219.