search

CircleCI-Public / jira-connect-orb

Display the status of CircleCI workflows and deployments in Jira!
https://circleci.com/orbs/registry/orb/circleci/jira
MIT License
25 stars 27 forks source link

Api patch [semver:patch] #31

Closed eddiewebb closed 4 years ago

eddiewebb commented 4 years ago

Checklist

Motivation, issues

Description

Whereas PIPELINE NUMBER is the only consistent, incremental value that spans jobs invoked by a single webhook event (containing a collection of commits). it is mapped to buildNumber which is repeated builds of the same project in jira model

Whereas REPO_NAME is the only consistent value that spans all activities of a project, it maps to "pipeline ID", which is like a build project in jira model

Where as RETRIES should be the same pipelined, but replace build, we get this for free since pipeline remains the same [1] [2] through workfklows that are retries.

Where as updateSequenceNumber is some incremental indicator of freshness, we use epoch.

Where as, all this fits 💯 with the UI of our product.

Builds

Here lots of builds, jira shows latest

Circleci

Screen Shot 2020-02-28 at 8 33 51 PM

Jira

Screen Shot 2020-02-28 at 8 33 59 PM

Deployments

Circleci

Screen Shot 2020-02-28 at 8 42 55 PM

JIra

Screen Shot 2020-02-28 at 8 42 39 PM

1 2

eddiewebb commented 4 years ago

Any job failure (https://circleci.com/workflow-run/da85474a-36e1-4240-a525-d8e808a29112) marks jira failure https://eddiewebb.atlassian.net/browse/CC-26

passing workflows show too. You can see these values are incremented. You can re-run either workflow and the jira should show thagt the number stayed the same, but status will update.

I think we should merge this alone, but I also just realized that we can use the workflows job endpoint and possible work out dependencies to send pending instead of success for intermediate jobs. (its sugar since Jira will only reflect during length of workflow)

eddiewebb commented 4 years ago

I marked this as major, but then dropped all the way to patch, here's why.

  1. Build numbers will jump from 1 to (something greater than 1) so data from this orb is guaranteed to work with existing data.
  2. it is important people adopt this.

The one risk (i see) to move back to major:

the UI description they see in jira will still say #xxx your project but #xxx will jump from latets build_num to latest pipeline_num, which is almost guaranteed to be lower than build. That may be confusing, but since it should squash all other, it should be ok.

eddiewebb commented 4 years ago

@KyleTryon - I can collab tomorrow (Tuesday) if you want, anytime before 10 or after 1

KyleTryon commented 4 years ago

@KyleTryon - I can collab tomorrow (Tuesday) if you want, anytime before 10 or after 1

Heck ya 🎉 . I believe it is very close but happy to collab (especially given the time crunch). I am available at the same times as well

eddiewebb commented 4 years ago

@KyleTryon I realize I cant just slack you anymore, lol . I am free until 1:45 and again at 2:30. Send an invite to ewebb @ atlassian.com

KyleTryon commented 4 years ago

@eddiewebb my tests are failing locally but I think that has something to do with my environment. I pushed up the changes we discussed and included a test specifically to check for an invalid response when an invalid service ID is sent.

Would love if you could give this a final look. I would also like to confirm 100% that the output in JSD we are seeing is in fact what we want to see.

Free for the rest of the day as well if you are available.

Here is the latest passing test: https://app.circleci.com/pipelines/github/CircleCI-Public/jira-connect-orb/174/workflows/34271a6f-9e6b-4d41-bd0b-c6335be20798/jobs/384/artifacts

cpe-bot commented 4 years ago

BotComment: Production version of orb available for use - circleci/jira@1.1.4