I mean, the code will account for those differences

Oh, I thought you could limit it to target environments

There can be different paths based on module or environment deploys

If it waits for completion, it can't be used with gitlab at least.

Yeah, for GitLab I'd probably drop 2 jobs. Deploy => Check (with retry and delay)

"Create a script/plugin for r10k/puppet server/bolt/choria that will send a notification message" Isn't that pretty much what the chatops bit is for?

Not necessarily

If running async, then all chatops will do is report if the request was accepted or failed

oh. I would have the chatops bit wait for the actual r10k run to pass or fail.

It could depending on how things are handled, but if something like bolt or choria is running, you'll want those to notify if there's a failure on specific machines

You could also (optionally) send out a message when a job is accepted, but there are already ways to tie webhooks to slack directly if eg. a SCM branch is updated.

googles generic solutions to queueing webhooks.

There are several. For generic in golang, it's using the built-in goroutines 😉

but there are ways that use separate processes entirely similar to sidekiq

sidekiq \o/

I would think that a 202 returning a callback would allow chatops (or whatever) to poll for completion

Our existing setup is using bitbucket server and a custom python service to process the hooks. I'm under quite a lot of pressure to just adapt that, (which is a shame as I really wanted to get our migration to gitlab going with webhook-go).

@Lumiere It should, but again depends on what's being done. If we're talking a multi-server system, then chances are puppet or choria are being used to remotely execute r10k on several puppet servers. Then you need to know the individual results which would be easier to implement on a bolt or choria side than trying to parse the output of those commands.

Does bolt not give you back a single 0 exit code if all executions were successful?

I'd assume so, but not worried about successes, but failures. Vague errors are useless, though

Anyway, not ready for async operations yet. Need more time available to get to that.... after packaging and containers are done..... and docs are better

ok. If you think that's the right order. Not usable for me at least without async.

Even with async, there will be a time limit option to prevent OOM errors and the like

Makes sense.

@dhollinger yes, but at least ansible has a method of hitting a url and collecting a response until it successes

it's all a mess though, yes

bleh, acceptance tests for EL on puppetlabs-* modules are broken and I have no idea why

EL8 or 7?

(or something else)

I think I've seen it on RPM install of puppet-agent, but it's so unclear in the output