make watch job more efficient #70
Conversation
… recognize when we're definitely done (no blocked or running jobs)
toshok
force-pushed
the
toshok.more-efficient-watch
branch
from
d5efd7d
to
007c1ec
Compare
| for _, job := range wfJobs { | ||
| // always count ourself as finished so we don't wait for ourself | ||
| // skip ourself so we don't wait if we're the only job running | ||
| if job.Name == jobName { | ||
| continue | ||
| } | ||
|
|
||
| switch job.Status { |
There was a problem hiding this comment.
should we introduce a default stanza here to deal with unknown CircleCI states in case they introduce a new one?
There was a problem hiding this comment.
yeah good call. hm, what should that stanza actually do though? ideally we'd include it in instrumentation, so we'd need to bubble it up someplace where we can send it.
There was a problem hiding this comment.
treat it as a failure state, I'd say?
There was a problem hiding this comment.
that worries me, anyone using circleci + buildevents would see failed builds if the watch job turns red, as opposed to broken traces
There was a problem hiding this comment.
maybe treat it such that we don't early exit and run through the 2 minute "we think we might be done, sleeping and trying again" loop in the hopes that it'll change to a state we recognize, and also send it up in instrumentation? we can run a trigger against our own builds that would surface it.
There was a problem hiding this comment.
going to address this in another PR so we have more space/time to think about it 👍
We've had a couple of releases that didn't end up getting updated in `orb.yml`. Skip them and update directly to 0.4.11 to pull in the watch step improvement in honeycombio/buildevents#70
…ite_env * 'main' of github.com:honeycombio/buildevents: (40 commits) add apply labels workflow (#93) GitLab CI example (#90) Build an arm64 release (#91) * publish a draft release to GitHub (#87) Prepare for 0.5.0 release, add changelog (#86) Add support for overriding default fields (#76) fix providerAzurePipelines in main.go (#84) add bitbucket support (#85) Ensure PRs from forks can run CI checks (#82) added quiet option to cmd (#80) Use public CircleCI context for build secrets (#77) add codeowners with integration-team (#78) Encode spaces in dataset names for the URL (#73) Add beeline-style propagation of the cmd context to called commands (#74) we're on circle for this, no need to build on travis any longer (#69) make watch job more efficient (#70) drop vendor/ and upgrade go to 1.15.2 (#68) add GitHub actions as a supported CI provider, with data from env vars Correct a download link Add support for Azure Piplines and some initial env vars ... # Conflicts: # README.md # cmd_root.go # common.go # main.go
keep track of whether or not we have blocked jobs. this should let us know for certain when we're actually done, so we can stop waiting sooner.
We can stop and declare the build finished as soon as there are no running jobs (minus the watch job itself) and no blocked jobs.
Simplify the loop inside
evalWorkflowto have no early returns, and just set another flag -anyRunning, which is true for jobs in either thequeuedorrunningcircleci states.The loop inside
waitCirclecontinues to confound and is next on the list of places we should simplify, imo.