Send intermediate statuses during multi-job workflows [semver:minor] #32
Conversation
eddiewebb
requested review from
KyleTryon
and removed request for
felicianotech and
iynere
eddiewebb
changed the title
|
I actaully think we shoul;d go full on and add #33, it shouldnt be too hard, and result would be
|
There was a problem hiding this comment.
Super impressive stuff. Took a while to trace everything out. Thank you for the mermaid chart. Looks fairly fault-tolerant to me, which is something I worry about when relying on the API for job statuses but this looks to be a great approach 👍 . I did comment on one minor concern below.
For the deployment, I wonder if maybe we should push a major version change to appease semver and also perhaps do some sort of user testing. we could then later manually publish the update as an older minor update to bring the bulk of users up to speed once we have some feedback.
Im mostly worried there could be an unforseen issue that translates to negative feedback if a user is set to a major version number.
| ./yaml2json /tmp/config.yml > /tmp/config.json | ||
| for dep_job_name in ${My_DEP_JOBS}; do | ||
|
|
||
| IS_DEPLOY=$(jq -r --arg jobname "${dep_job_name}" '.jobs[$jobname].steps[] | select(.>={}) | select(.run.name =="Update status in Atlassian Jira") | .run.command | contains("deployment\" == \"deployment")' /tmp/config.json) |
There was a problem hiding this comment.
Might there be an issue here if the upstream deploy job is set to only run on a particular branch (master) and the current branch is something else? I believe this may need to also consider filter logic.
example:
workflows:
version: 2
build-test-and-deploy:
jobs:
- build
- deploy:
requires:
- build
filters:
branches:
only:
- master
|
Coming back around to this on Monday, since it's a holiday in the US. @KyleTryon Going to need a hand with the failing tests. |
|
Given the lack of activity on this PR, coupled with webhooks entering preview on CircleCI and the increasing complexity of the scripts powering this orb, I'm going to opt to close this PR unless someone else would like to pick it up. |
Checklist
DO NOT MERGE BEFORE #31
Motivation, issues
Currently all jobs send a
successfulorfailedstatus, which is true of the job, but not the workflow if we know subsequent jobs are about to run.This change will inspect the workflow for downstream jobs.
Multi-job workflows will now send intermediate status instead of pass/fail
in_progresswhen additional jobs are yet to completependingwhen next jobs contain an approval jobsuccesfulto build status on any deployment (otherwise would be left pending)Final jobs or single-job workflows will behave as before,.
Description
Running Jobs
Approval Jobs
Full logic