cloud-builders-community icon indicating copy to clipboard operation
cloud-builders-community copied to clipboard

Slackbot notification builder ignores the time out of the build is monitoring

Open juandelgado opened this issue 7 years ago • 2 comments

Hi there : )

When triggering the secondary build to monitor the state of the main build, the timeout of the main build is ignored.

So even if in my cloudbuild.yaml I set up a build time out of 900s, if my build happens to go over 600s no notification will be sent because the monitoring build will time out after 600s.

I've quickly hacked this in trigger.go hardcoding my own time out when creating the trigger:

		Tags: []string{"slackbot"},
		Timeout: "900s", // <--- I added this

Ideally Slackbot should pull the timeout information from the Cloud Build API in order to use the same or maybe slightly higher. But I haven't checked that this is possible and my Go knowledge is non-existent!

Thanks,

Juan

juandelgado avatar Jan 11 '19 13:01 juandelgado

Ooh, good idea! Your hack looks good to me (so your Go is good enough!)

One slight problem: the monitoring build - including its timeout - must be submitted before it can poll the Cloud Build API and get the timeout of the main build.

We could add some more blurb into the README, giving people a heads up that builds with extended timeout need to have a matching timeout added there too. It's not a great solution, but then at least it wouldn't come as a surprise. What do you think?

nof20 avatar Jan 12 '19 00:01 nof20

the monitoring build - including its timeout - must be submitted before it can poll

That makes sense, but I was guessing this would be work done by the main build, right at the time it creates the monitoring build. Again, not sure if the main build can query itself for the time out data.

We could add some more blurb into the README, giving people a heads up that builds with extended timeout need to have a matching timeout added there too

Yeah, definitely mention it on the README so it doesn't surprise people.

Also, and this caught me by surprise too, isn't the monitoring build effectively doubling up the usage of Cloud Build? This has cost implications right? There might not be another way around it, since it doesn't look like Cloud Build has "catch all" steps that get executed regardless of success / failure, but it would be good to document it.

Thanks!

juandelgado avatar Jan 14 '19 08:01 juandelgado