circleci-public / jira-connect-orb Goto Github PK

Orb version

1.3.1

What happened

job_type deployment throws a ERROR: unknown association error.

Example redacted output for a deployment workflow:

"github-username"
This job is passing, however another job in workflow is success
Update Jira with status: successful for 63
Results from Jira: 
ERROR: unknown association
{
  "acceptedDeployments": [
    {
      "pipelineId": "repo-name",
      "environmentId": "ce36f16f-9b7f-4e36-8bb4-0262ca0a7e6f-Deploy to Dev",
      "deploymentSequenceNumber": 63
    }
  ],
  "rejectedDeployments": [],
  "unknownIssueKeys": [],
  "unknownAssociations": [
    {
      "associationType": "serviceIdOrKeys",
      "values": [
        ""
      ]
    }
  ]
}

CircleCI received exit code 0

Oddly enough, the deployment is not rejected, and the final exit code is 0 (CircleCI received exit code 0)

Expected behavior

Both build AND deployment job types don't throw errors?
Or if this mentioned error is more like a warning (what I'm assuming since the exit code is 0 and the deployment doesn't get rejected) it should be outputted as a Warning or Info message.

Config yaml

version: 2.1
orbs:
  jira: circleci/[email protected]

jobs:
  build-and-deploy-jira:
    docker:
      - image: mobomo/drupalstand-ci:0.1.4
    steps:
      - checkout
      - run: echo "Holu :)"

workflows:
  version: 2

  commit:
    jobs:
      - test:
          post-steps:
            - jira/notify # default "build" job_type it shows no errors.

# Deployment for testing.
  manual-deploy:
    jobs:
      - approve-dev-deployment:
          type: approval
          filters:
            branches:
              only: 
                - develop
      - build-and-deploy-jira:
          name: Deploy to Dev
          post-steps:
            - jira/notify:
                environment_type: development
                job_type: deployment
          requires:
            - approve-dev-deployment

More details

/tmp/jira-status.json

{
  "deployments": [
    {
      "schemaVersion": "1.0",
      "pipeline": {
        "id": "repo-name",
        "displayName": "#63 repo-name",
        "url": "https://circleci.com/workflow-run/ce36f16f-9b7f-4e36-8bb4-0262ca0a7e6f"
      },
      "deploymentSequenceNumber": "63",
      "updateSequenceNumber": "1614813995",
      "displayName": "#63  repo-name - Deploy to Dev",
      "description": "repo-name #63 Deploy to Dev Deploy to Dev",
      "url": "https://circleci.com/gh/username/repo-name/91",
      "state": "successful",
      "lastUpdated": "2021-03-03T23:26:35+00:00",
      "associations": [
        {
          "associationType": "issueKeys",
          "values": [
            "ABC-1234",
            "ABC-1234"
          ]
        },
        {
          "associationType": "serviceIdOrKeys",
          "values": [
            ""
          ]
        }
      ],
      "environment": {
        "id": "ce36f16f-9b7f-4e36-8bb4-0262ca0a7e6f-Deploy to Dev",
        "displayName": "Deploy to Dev",
        "type": "development"
      }
    }
  ]
}

/tmp/curl_response.txt

{
  "acceptedDeployments": [
    {
      "pipelineId": "repo-name",
      "environmentId": "ce36f16f-9b7f-4e36-8bb4-0262ca0a7e6f-Deploy to Dev",
      "deploymentSequenceNumber": 63
    }
  ],
  "rejectedDeployments": [],
  "unknownIssueKeys": [],
  "unknownAssociations": [
    {
      "associationType": "serviceIdOrKeys",
      "values": [
        ""
      ]
    }
  ]
}

$ cat project/circleci-orb-jira.status
JIRA_BUILD_STATUS="successful"

So... what I guess I'm trying to clarify is if that "unknown association" error is actually an error preventing something in the Orb functionality to work, OR if we can ignore it and probably best to output it as Info message.

Thanks!

m

Orb version

1.1.2

What happened

I just found out we're using an older orb than 1.1.2 and went to look at the code changes that have happened since then. Only version 0.0.1 is tagged as a release.

I'm able to find the source code for v1.1.2 in the orb registry -- https://circleci.com/orbs/registry/orb/circleci/jira?version=1.1.2 -- so I can manually diff the code changes, but it would be nice if I could leverage Github's code diff capabilities to compare versions.

I couldn't find a changelog either.

Expected behavior

Orb dev team tags releases in the Github repo -- and perhaps also includes a changelog as well

Orb version

Orb version: 1.0.5
Passing job: https://bit.ly/2YN8DAl
Failing job: https://bit.ly/2Kvt7sl

What happened

I have jira-notify specified as the sole post-step for a job in my CircleCI config. When that job passes, the steps 'Install jq', 'JIRA - Setting Success Condition', and 'Update status in Atlassian Jira' run and everything works as expected. That said, when the job fails, the 'Install jq' step seems to be bypassed and the 'Update status in Atlassian Jira' step throws this error:

environment: line 25: jq: command not found
Exited with code 127

Expected behavior

Both passing and failing jobs trigger the appropriate sequential steps, beginning with 'Install jq' and the 'Update status in Atlassian Jira' step completes without error.

Orb version: 1.3.1

What happened

Unable to find an API call or environment variable to set to set the Atlassian Connect for CircleCI token for a project which means this has to be done manually.

Expected behaviour

Able to set the Atlassian Connect for CircleCI token via code rather than through the UI.

Orb version: 1.3.0

What happened

install JQ fails:

Here is the output of that step:

  #!/bin/bash -eo pipefail
# Quietly try to make the install directory.
mkdir -p ~/bin | true

# Selectively export the SUDO command, depending if we have permission
# for a directory and whether we're running alpine.
if [[ $EUID == 0 ]]; then export SUDO=""; else # Check if we're root
  if cat /etc/issue | grep Alpine > /dev/null 2>&1 || ! [[ -w "~/bin" ]]; then
    export SUDO="sudo";
  fi
fi

# If our first mkdir didn't succeed, we needed to run as sudo.
if [ ! -w ~/bin ]; then
  $SUDO mkdir -p ~/bin
fi

echo 'export PATH=$PATH:~/bin' >> $BASH_ENV
source $BASH_ENV

# check if jq needs to be installed
if command -v jq >> /dev/null 2>&1; then

    echo "jq is already installed..."

  if [[ true == true ]]; then
    echo "removing it."
    $SUDO rm -f $(command -v jq)
  else
    echo "ignoring install request."
    exit 0
  fi
fi

# Set jq version
if [[ latest == "latest" ]]; then
  JQ_VERSION=$(curl -Ls -o /dev/null -w %{url_effective} "https://github.com/stedolan/jq/releases/latest" | sed 's:.*/::')
  echo "Latest version of jq is $JQ_VERSION"
else
  JQ_VERSION=latest
fi

# extract version number
JQ_VERSION_NUMBER_STRING=$(echo $JQ_VERSION | sed -E 's/-/ /')
arrJQ_VERSION_NUMBER=($JQ_VERSION_NUMBER_STRING)
JQ_VERSION_NUMBER="${arrJQ_VERSION_NUMBER[1]}"

# Set binary download URL for specified version
# handle mac version
if uname -a | grep Darwin > /dev/null 2>&1; then
  JQ_BINARY_URL="https://github.com/stedolan/jq/releases/download/${JQ_VERSION}/jq-osx-amd64"
else
  # linux version
  JQ_BINARY_URL="https://github.com/stedolan/jq/releases/download/${JQ_VERSION}/jq-linux64"
fi

jqBinary="jq-$PLATFORM"

if [ -d "$JQ_VERSION/sig" ]; then
  # import jq sigs

  if uname -a | grep Darwin > /dev/null 2>&1; then
    HOMEBREW_NO_AUTO_UPDATE=1 brew install gnupg coreutils

    PLATFORM=osx-amd64
  else
    if cat /etc/issue | grep Alpine > /dev/null 2>&1; then
      $SUDO apk add gnupg > /dev/null 2>&1
    fi
    PLATFORM=linux64
  fi

  gpg --import "$JQ_VERSION/sig/jq-release.key" > /dev/null

  curl --output "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER/jq-$PLATFORM" \
      --silent --show-error --location --fail --retry 3 \
      "$JQ_BINARY_URL"

  # verify sha256sum, sig, install

  gpg --verify "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER/jq-$PLATFORM.asc"

  pushd "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER" && grep "jq-$PLATFORM" "sha256sum.txt" | \
  sha256sum -c -
  popd
  jqBinary="$JQ_VERSION/sig/v$JQ_VERSION_NUMBER/jq-$PLATFORM"

else
  curl --output "$jqBinary" \
    --silent --show-error --location --fail --retry 3 \
    "$JQ_BINARY_URL"
fi

$SUDO mv "$jqBinary" ~/bin/jq
$SUDO chmod +x ~/bin/jq

# cleanup
[[ -d "./$JQ_VERSION" ]] && rm -rf "./$JQ_VERSION"

# verify version
echo "jq has been installed to $(which jq)"
echo "jq version:"
echo "$(jq --version)"
/tmp/.bash_env-5fe6730342b32261338060d6-0-build: line 2: export: `********************************************': not a valid identifier
/tmp/.bash_env-5fe6730342b32261338060d6-0-build: line 2: export: `********************************************': not a valid identifier

Exited with code exit status 1
CircleCI received exit code 1

-->

The workflow failed because of the JQ installation,
The JIRA connection functions on my Jira service management as a change request but without defining the failure or the success of the workflow.

Expected behavior

The success of the workflow but it gives fails because the JQ install fails.
Showing the success or the failure of the workflow at the Jira service management change request.

Orb version

1.3.0

What happened

Hello!

I'm trying to use https://circleci.com/developer/orbs/orb/circleci/jira orb in one of my projects based on gitflow. So, basically, i have two main branches - master and dev. All the ongoing work is merged into dev and once the version/sprint is complete, i merge dev into master. Hotfixes goes straight to master.

Here is my circleci config file:

version: 2.1

orbs:
  webhook: eddiewebb/webhook@volatile
  jira: circleci/[email protected]

jobs:
  build_test:
    working_directory: ~/xxx
    docker:
      - image: circleci/ruby:2.7.0-node-browsers
        environment:
          RAILS_ENV: test
          DATABASE_URL: postgres://[email protected]:5432/xxx
      - image: circleci/redis:5.0.3
      - image: circleci/postgres:11.6
        environment:
          RAILS_ENV: test
          POSTGRES_USER: root
          POSTGRES_DB: xxx

    steps:
      - checkout
      - run:
          name: Run RSpec tests
          command:
            bundle exec rspec --format RspecJunitFormatter -o
            /home/circleci/pass-manager/test-results/rspec/rspec.xml -p
      - jira/notify

  deploy_staging:
    working_directory: ~/xxx
    docker:
      - image: circleci/node:10
    steps:
      - webhook/notify:
          endpoint: xxx
      - jira/notify

  deploy_production:
    working_directory: ~/xxx
    docker:
      - image: circleci/node:10
    steps:
      - checkout
      - jira/notify

workflows:
  version: 2
  test_and_deploy:
    jobs:
      - build_test
      - deploy_staging:
          post-steps:
            - jira/notify:
                environment: staging
                environment_type: staging
                job_type: deployment
          requires:
            - build_test
          filters:
            branches:
              only: dev

  deploy_production_notify:
    jobs:
      - deploy_production:
          post-steps:
            - jira/notify:
                environment: production
                environment_type: production
                job_type: deployment
          filters:
            # ignore any commit on any branch by default
            branches:
              ignore: /.*/
            # only act on version tags
            tags:
              only: /^v.*/

And the thing is - when i'm merging my PRs into dev branch, all works perfectly well and deployment statuses of tasks are being reported to Jira. On the other hand, when i merge into master and do a deployment on there (using tags v.*), jira orb reports that it was not able to find any issue keys.

jira/notify of deploy_production job output:

{
  "acceptedBuilds": [],
  "rejectedBuilds": [
    {
      "key": {
        "pipelineId": "xxx",
        "buildNumber": 540
      },
      "errors": [
        {
          "message": "At least one 'issueKeys' is required"
        }
      ]
    }
  ],
  "unknownIssueKeys": []
}

jira/notify of deploy_production_notify workflow output:

ERROR: unknown association
{
  "acceptedDeployments": [],
  "rejectedDeployments": [
    {
      "key": {
        "pipelineId": "xxx",
        "environmentId": "xxx",
        "deploymentSequenceNumber": 540
      },
      "errors": [
        {
          "message": "No valid associations found for deployment"
        }
      ]
    }
  ],
  "unknownIssueKeys": [],
  "unknownAssociations": [
    {
      "associationType": "serviceIdOrKeys",
      "values": [
        ""
      ]
    }
  ]
}

What's interesting is that merging master back to dev (obviously) triggers the deployment notification and jira deployment notification works in there properly! Which makes me think it's nothing strictly related to jira orb itself and that it has something to do with a fact that I'm using tags/releases.

Thanks in advance for any clues.

Expected behavior

The code to check the VCS type currently checks for the presence of github.com in the repository URL and would not work for GitHub enterprise.

Refer:

Orb version

1.1.4

What happened

verify_api_key

This causes project tokens to fail with a 401 "You must log in first"

Expected behavior

Either verify the token in a way that is compatible with project tokens or remove the check

Orb version

circleci/[email protected]

What happened

when i use circleci/[email protected], i got an error in the step "Update status in Atlassian Jira":

"shinji3887"
This job is passing, however another job in workflow is running
Results from Jira: 

{
  "acceptedBuilds": [],
  "rejectedBuilds": [
    {
      "key": {
        "pipelineId": "jiratest",
        "buildNumber": 13
      },
      "errors": [
        {
          "message": "At least one 'issueKeys' is required"
        }
      ]
    }
  ],
  "unknownIssueKeys": []
}

and i use the example yml in this url : https://circleci.com/developer/orbs/orb/circleci/jira?version=1.3.1 like:

jobs:
  build:
    docker:
      - image: 'circleci/node:10'
    steps:
      - run: echo "hello"
orbs:
  jira: circleci/[email protected]
version: 2.1
workflows:
  build:
    jobs:
      - build:
          post-steps:
            - jira/notify

and my jobs in circle-ci looks work well

please help me.

Hi! Both build and deployment notifications work great, however I think it would be event better if it was possible to somehow let the orb know what is the URL to deployment. I'm gonna use your issue template for this feature request even thought it's more suited for bug reports 😉

Orb version

1.0.2

What happened

job_type: deployment links to CircleCI job, which makes more sense for build type:

Expected behavior

It would be great if job_type: deplyoment additionally linked to actual release (quick mockup):

I am not sure what is the best way to approach this, but it could be parameter that we use with the orb, like the environment_type or maybe there's an easier way like setting an environment variable.

Orb version

1.3.1

What happened

Hi! We're having issues with reporting production deployments only. It works as expected for development deployments.

I found one case where it worked:

• https://app.circleci.com/pipelines/github/Kamion/kamion_server/3019/workflows/769a8261-a53d-4e42-9c13-3122705c0413/jobs/8685

And in the second case it didn't:

• https://app.circleci.com/pipelines/github/Kamion/kamion_server/3199/workflows/11fad98d-56c7-4c64-9e13-aec5e4d54212/jobs/9077

Is there any context behind this error: "No valid associations found for deployment"?

Also, I see that you're using some internal CircleCI API to report to JIRA. Is there a documentation for this endpoint?

Expected behavior

Ideally, it should work.

Hi There -

Can you provide additional information in the README regarding the ideal workflows for this ORB to properly notify Jira of issue state? From looking at the code, it appears as though it will only notify of an issue if it can read the issue number in the most recent commit.

Imagine a gitflow workflow (https://datasift.github.io/gitflow/IntroducingGitFlow.html) where a 'release' to master is a single deploy that contains many commits in a develop branch. Would this be usable in that case?

Orb version

1.3.1

What happened

Jira's build data API has optional test results parameters:

      "testInfo": {
        "totalNumber": 150,
        "numberPassed": 145,
        "numberFailed": 5,
        "numberSkipped": 0
      },

Expected behavior

Orb supports passing test_info_total_number, test_info_number_passed, test_info_number_failed, and test_info_number_skipped integers into build notification job_types.

Orb version 1.1.2

What happened

Using this orb, is it possible to notify JIRA about build in running state? I only see build status once it failed or succeeded.

Orb version

1.3.1

What happened

Curl failed with code 401. full response below.
{
  "message" : "You must log in first."
}

Exited with code exit status 1

Debug output says

post_to_jira () {
  HTTP_STATUS=$(curl \
  -u "${CIRCLE_TOKEN}:" \
  -s -w "%{http_code}" -o /tmp/curl_response.txt \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -X POST "https://circleci.com/api/v1.1/project/${VCS_TYPE}/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/jira/build" --data @/tmp/jira-status.json)

That does not look like a valid basic auth to me.

Expected behavior

It should post the status. My experience with JIRA basic auth has been that it demands "[email protected]:token" not "token:" I don't see anything in the documentation for the JIRA orb that states otherwise.

Orb version

1.0.5

What happened

Users complaining that missing issue in commit/branch will fail the job.
https://marketplace.atlassian.com/apps/1215946/circleci-for-jira?hosting=cloud&tab=reviews

Expected behavior

Although users might want a highly disciplined workflow (why work on things without wok items) it is clear many dont.

I suggested we default to a soft pass, and allow parameter to override.

Orb version

0.1.4

What happened

A user utilized the JIRA orb on a custom Docker image without JQ installed and experienced an error.

Attempt to get Jira Issues from  https://circleci.com/api/v1.1/project/bitbucket/x/x/xxxx
/bin/bash: line 25: jq: command not found
Exited with code 127

Expected behavior

For newer users, this message may be confusing for those that expect the integration to "just work". A better solution may be to add a check for required dependencies and gracefully error with instructions to resolve.

Orb version

1.3.1

What happened

The Jira orb requires a CircleCI personal access token (PAT) in the job's environment to run. This is insecure, because it means that anyone with access to the CircleCI job can act on behalf of the user.

Consider the following CCI configuration:

version: 2.1

orbs:
  jira: circleci/[email protected]

jobs:
  jira:
    docker:
      - image: cimg/base:2021.03
    steps:
      - jira/notify
      - echo $CIRCLE_TOKEN
workflows:
  main:
    jobs:
      - jira

In this example, I have set $CIRCLE_TOKEN to my Personal Access Token.
Imagine this configuration is for an organization's repository. Suppose the line echo $CIRCLE_TOKEN was injected by an attacker who can access my organization's build logs. Then, they would gain access to my account via the PAT.

This is not an unreasonable situation; an angry coworker could gain access to my PAT and perform actions on my behalf, and it could prove challenging to procedure the audit log leading back to them.

Further, running this job even logs who the PAT belongs to. See the image below for a example log.

That means an attack, by default, knows who they are targeting. It would be easy to remove that log line to obscure who the PAT belongs to, though the CCI API allows any PAT holder to identify themselves with an API call.

Expected behavior

The Jira orb should access a Project API Token in addition to a PAT.

I understand that this project previously switched from using a Project API Token to a PAT, but I can't find documentation on why that decision was made. Could you provide guidance on how to use this orb securely? With respect, it appears to be insecure by default, and I'm afraid I can't figure out how to secure my PAT or prevent exposing it.

Orb version 1.1.2

What happened

The Install jq step did install jq successfully, but still reports a failure condition (Exit code 1).

Here is the build

Here is the output of that step:

#!/bin/bash --login -eo pipefail
if [[ $EUID == 0 ]]; then export SUDO=""; else export SUDO="sudo"; fi

# grab jq version
if [[ latest == "latest" ]]; then
  # extract latest version from GitHub releases API
  JQ_VERSION_STRING=$(curl --silent --show-error --location --fail --retry 3 \
    https://api.github.com/repos/stedolan/jq/releases/latest | grep tag_name | sed -E 's/"/%/g')

  IFS='%'; arrJQ_VERSION=($JQ_VERSION_STRING); unset IFS

  JQ_VERSION=${arrJQ_VERSION[3]}

  echo "Latest version of jq is $JQ_VERSION"
else
  JQ_VERSION=latest
fi

# check if jq needs to be installed
if command -v jq >> /dev/null 2>&1; then
  if jq --version | grep $JQ_VERSION >> /dev/null 2>&1; then
    echo "$JQ_VERSION is already installed"
    exit 0
  else
    echo "A different version of jq is installed ($(jq --version)); removing it"
    $SUDO rm -f $(command -v jq)
  fi
fi

# get source download URL for specified version
if [[ $(curl --silent --show-error --location --fail --retry 3 \
  "https://api.github.com/repos/stedolan/jq/releases/tags/$JQ_VERSION" | \
  grep browser_download_url | grep -o -e 'https.*tar.gz') ]]; then

  JQ_SOURCE_URL=$(curl --silent --show-error --location --fail --retry 3 \
  "https://api.github.com/repos/stedolan/jq/releases/tags/$JQ_VERSION" | \
  grep browser_download_url | grep -o -e 'https.*tar.gz')
else
  JQ_SOURCE_URL="https://github.com/stedolan/jq/archive/$JQ_VERSION.tar.gz"
fi

# download jq
curl -O --silent --show-error --location --fail --retry 3 \
  "$JQ_SOURCE_URL"

tar xf "$JQ_VERSION.tar.gz" && rm -rf "$JQ_VERSION.tar.gz"

# extract version number
JQ_VERSION_NUMBER_STRING=$(echo $JQ_VERSION | sed -E 's/-/ /')

arrJQ_VERSION_NUMBER=($JQ_VERSION_NUMBER_STRING)

JQ_VERSION_NUMBER="${arrJQ_VERSION_NUMBER[1]}"

# get binary download URL for specified version
# handle mac version
if uname -a | grep Darwin; then
  JQ_BINARY_URL=$(curl --silent --show-error --location --fail --retry 3 \
    "https://api.github.com/repos/stedolan/jq/releases/tags/$JQ_VERSION" | \
    grep browser_download_url | grep '/jq-osx.*64.*"' | \
    grep -o -e 'https.*jq-osx.*64.*' | sed -E 's%"%%g')
else
  # linux version
  JQ_BINARY_URL=$(curl --silent --show-error --location --fail --retry 3 \
    "https://api.github.com/repos/stedolan/jq/releases/tags/$JQ_VERSION" | \
    grep browser_download_url | grep '/jq-linux.*64.*"' | \
    grep -o -e 'https.*jq-linux.*64.*' | sed -E 's%"%%g')
fi

if [ -d "$JQ_VERSION/sig" ]; then
  # import jq sigs

  if uname -a | grep Darwin; then
    HOMEBREW_NO_AUTO_UPDATE=1 brew install gnupg coreutils

    PLATFORM=osx-amd64
  else
    if cat /etc/issue | grep Alpine >> /dev/null 2>&1; then
      $SUDO apk add gnupg > /dev/null
    fi
    PLATFORM=linux64
  fi

  gpg --import "$JQ_VERSION/sig/jq-release.key" > /dev/null

  curl --output "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER/jq-$PLATFORM" \
      --silent --show-error --location --fail --retry 3 \
      "$JQ_BINARY_URL"

  # verify sha256sum, sig, install

  gpg --verify "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER/jq-$PLATFORM.asc"

  cd "$JQ_VERSION/sig/v$JQ_VERSION_NUMBER" && grep "jq-$PLATFORM" "sha256sum.txt" | \
  sha256sum -c -

else
  curl --output "jq-$PLATFORM" \
    --silent --show-error --location --fail --retry 3 \
    "$JQ_BINARY_URL"
fi

$SUDO mv "jq-$PLATFORM" /usr/local/bin/jq
$SUDO chmod +x /usr/local/bin/jq

# verify version
echo "jq has been installed to $(which jq)"
echo "jq version: $(jq --version)"
/tmp/.bash_env-5e2a219a5f8cc1332f52cef2-0-build: line 2: warning: setlocale: LC_CTYPE: cannot change locale (en_US.UTF-8): No such file or directory
/tmp/.bash_env-5e2a219a5f8cc1332f52cef2-0-build: line 4: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
Latest version of jq is jq-1.6
jq-1.6 is already installed

Exited with code exit status 1

Although jq is successfully installed and the JIRA connection functions correctly, the build is recorded as a failure due to the Exit code of 1 on this step.

I am using the following executor:

    docker:
      - image: circleci/android:api-28-node8-alpha

This only happens on my Linux builds. My MacOS builds work just fine.

Expected behavior

The JIRA notification works and the jq installation does not return an Exit code of 1.

Expected behavior

Would be nice to have a command that can change an issue's status. Use is automation, for example when tests pass for a particular ticket/branch, ticket moves to Done, etc.

Example: https://community.atlassian.com/t5/Jira-Questions/JIRA-How-to-change-issue-status-via-rest/qaq-p/528133

Orb version

1.0.5

What happened

The state of the most recent job will be the workflow status reported in Jira.

"For instance, if RSpec takes the longest to run and fails then I’ll see failed in Jira but if cucumber takes the longest and passes while rubocop fails, I’ll see passed in Jira."

Expected behavior

See a single status in JIRA that shows the build status, linking to the entire workflow.

Orb version

1.1.2

What happened

When building a git tag in Circle, there is no branch. In the /tmp/job_info.json, the branch key is null.

• "branch": null,

Expected behavior

orb should fail gracefully upon not finding any ISSUE_KEYS

Orb version 1.1.2

Is it possible to report test results from JUnit XML format using this Orb? I used test metadata feature to see test results on build page, but I noticed in JIRA, there is a column called "test results", but it does not display anything.

Attaching image of my build status on JIRA:

Note "test results" are empty, but I can see test metadata on CircleCI build page.

Orb version

1.1.2

What happened

Running on image docker:18.06.3-ce-git, which is based of alpine 3.9.
jira/notify fails to install jq.
Error message is

sh: 0: unknown operand
/bin/sh: syntax error: unexpected "(" (expecting "fi")

This is due to jq/install using the /bin/sh shell instead of /bin/bash.
I've installed bash prior to running this task and it didn't fix the issue.

Expected behavior

jq/install states on their doc that they required bash but is not using it. Not sure id that is a circleci/jira issue or a circleci/jq issue. Please advise

Orb version

1.1.2

What happened

We were able to see successful and failing builds on JIRA ticket last week, but this week for some reason we can only see failed builds. Nothing has changed in CircleCI config

Inside CircleCI "Update status in Atlassian JIRA" step, I can see one difference for successful build, which might indicate why it is not posting status to ticket:

Job is passing, workflow is null
Results from Jira: 
Success!
{
  "acceptedBuilds": [
    {
      "pipelineId": "pi-app",
      "buildNumber": 1
    }
  ],
  "rejectedBuilds": [],
  "unknownIssueKeys": []
}

Notice, that message "Job is passing, workflow is null" is only visible on successful builds, hence this might indicate that issue is.

Expected behavior

I expect to see successful builds as well on JIRA ticket.

Orb version

1.3.1

What happened

Here is the circle config

workflows:
  build-deploy:
    jobs:
      - build:
          post-steps:
            - jira/notify
      - build-docker-image:
          requires:
            - build
          filters:
            branches:
              only: develop
      - deploy:
          requires:
            - build
            - build-docker-image
          filters:
            branches:
              only: develop
          post-steps:
            - jira/notify:
                job_type: deployment

The jira/notify job with type deployment fails with the following error:

error: scan is not defined
[.all_commit_details[].subject | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [.all_commit_details[].branch | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [if .branch then .branch else "" end | scan("([A-Z]{2,30}-[0-9]+)")  | . [] ] + [if false then .all_commit_details[].body else "" end | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ]                                 error: scan is not defined
[.all_commit_details[].subject | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [.all_commit_details[].branch | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [if .branch then .branch else "" end | scan("([A-Z]{2,30}-[0-9]+)")  | . [] ] + [if false then .all_commit_details[].body else "" end | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ]                                                                                                          error: scan is not defined
[.all_commit_details[].subject | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [.all_commit_details[].branch | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [if .branch then .branch else "" end | scan("([A-Z]{2,30}-[0-9]+)")  | . [] ] + [if false then .all_commit_details[].body else "" end | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ]                                                                                                                                                                                          error: scan is not defined
[.all_commit_details[].subject | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [.all_commit_details[].branch | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ] + [if .branch then .branch else "" end | scan("([A-Z]{2,30}-[0-9]+)")  | . [] ] + [if false then .all_commit_details[].body else "" end | scan("([A-Z]{2,30}-[0-9]+)")   | .[] ]                                                                                                                                                                                                                                                                                           4 compile errors

Exited with code exit status 3

Expected behavior

job should pass.

Orb version

1.3.1

What happened

We have a deploy job which has a post step to notify jira of a deployment:

workflows:
  version: 2
  build-test-deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only: main
          post-steps:
            - jira/notify:
                job_type: deployment
                environment_type: production

We get a success message back from Jira:

{
  "unknownIssueKeys": [],
  "acceptedBuilds": [
    {
      "pipelineId": "booking-system",
      "buildNumber": 613
    }
  ],
  "rejectedBuilds": []
}


Success!

But nothing appears on the Jira deployment page and the "cycle time report" says "more data required".

Expected behavior

We see the deployments in Jira.

Note that notifying of builds works just fine.

When the job type is deployment the docs say: "Note that Deployments require additional details", are we missing anything? I'm not sure what the additional details are.

Orb version

1.0.5

What happened

First of all, thanks for this plugin. I was able setup orb/plugin/config so it would update build status for ticket in Jira. So, the configuration, plugin setup, etc. are correct. But I've got a CircleCI workflow setup in a slightly more complex manner than example config. Here's a screenshot

Note: teaspoon_tests, rspec_tests and cucumber_test have parallelism setup to > 1

So I'd like to know if there's a way to setup orb in a way that it will notify JIRA only once, when all jobs in the pipeline are done(succeeded or failed)

Here's what I tried so far:

1. Added post-steps: - jira/notify to each job. But this leads to JIRA api being called multiple times. 1 time per job + jobs with parallelism call it once for every parallel executor. As far as I understand this means that only latest result will be displayed in JIRA. If one job fails and reports failed status, and another job after that succeeds JIRA will display successful build status.

2. Tried to add it as a separate job in the workflow that runs after all jobs are done, but it is only executed if all previous jobs are successful(didn't find a way to make it happen in either case). As far as I understand it means that JIRA will only receive successful states. It looks something like this
   

So, I'm looking for some guidance here. Is there a way to make it work? Are my assumptions about how it works correct? I'm happy to provide any further details.

Orb version

circleci/[email protected]

What happened

Windows executor's default shell is powershell.exe, so the jira scripts expecting bash fail immediately. bash.exe is available on these machines, but I can't figure out how to specify the shell to use with the orb.

Minimal example

version: 2.1

orbs:
  windows: circleci/[email protected]
  jira: circleci/[email protected]

jobs:
  build-win:
    executor:
      name: windows/default
    steps:
      - run:
          command: echo dummy step

workflows:
  build-all:
    jobs:
      - build-win:
          post-steps:
            - jira/notify

Expected behavior

jira/notify works out of the box on Windows executors

I am opening this on behalf of a customer who wrote in to support.

Orb version

circleci/[email protected]

What happened

The build passed and the success condition was set.

echo 'export JIRA_BUILD_STATUS="successful"' >> $BASH_ENV

When attempting to post this to JIRA the following error message is displayed.

Attempt to get Jira Issues from  https://circleci.com/api/v1.1/project/github/$REDACTED/1151
Associating build with [
  "CS-613",
  "CS-613"
] on 
{"acceptedDeployments":[],"rejectedDeployments":[{"key":{"pipelineId":"service-public-api-old","environmentId":"4e16cfe8-f6a1-4336-8f8f-8f02c0632bb5-deploy-development","deploymentSequenceNumber":1151},"errors":[{"message":"'state' is required"},{"message":"'state' is not valid. Allowed values are: [pending, in_progress, successful, cancelled, failed, rolled_back, unknown]."}]}],"unknownIssueKeys":[]}Success!

Expected behavior

The success status is posted to JIRA without issue.

Orb version

1.1.4

What happened

When you execute the the jira/notify this execute the following line to verify if your token is valid

verify_api_key () {
  URL="https://circleci.com/api/v2/me"
  fetch $URL /tmp/me.json
  jq -e '.name' /tmp/me.json
}

The problem is for some weird reason my name is not set in the circle ci returning the following output
(example api response)
{
"name": null,
"login": "my_login_name",
"id": "a numeric id"
}

200:https://circleci.com/api/v2/me
null

Exited with code exit status 1

Expected behavior

You need change the look up field for the field login to verify the information.

Orb version

1.3.0

What happened

Hi there, I wonder why my CIRCLE_TOKEN value has to be my personal token if the project is company-wide? If the idea is to check me, it will be me every time. 😕

Expected behaviour

Use an ORG token instead of the personal.

Orb version

1.3.0

What happened

I am trying to integrate the orb for my build and release pipeline for an Android project. There is a job for build and test step. Adding "jira/notify" works well.

In addition to that I am trying to add a "jira/notify" for a deployment. The job is triggered via fastlane lane. When inluding the command with default values, it works well, but when adding the job_type and environment_type it fails on CircleCI with error:

Cannot find a definition for command named notify

Error calling job: 'assemble_beta_apk_with_firebase'

Error calling workflow: 'assemble_beta_apk_with_firebase'

Here is the job definition, some parts are omitted.

Configuration that works:

version: 2.1

orbs:
    jira: circleci/[email protected]

...

  assemble_beta_apk_with_firebase:
    <<: *android_config
    environment:
    steps:
      - *checkout_code
      - *android_dependencies
      - run:
          name: Clean old APK's
          command: |
            cd workspace/App
            ./gradlew clean
      - run:
          name: Install Firebase CLI
          command: |
            curl -sL firebase.tools | bash
      - run:
          name: Build beta APKs and upload to Firebase App Distribution
          command: |
            cd workspace/App
            bundle exec fastlane android distribute_branch_with_temp_version_name branch_name:${CIRCLE_BRANCH}`
      - jira/notify

...

Configuration that produced the error:

version: 2.1

orbs:
    jira: circleci/[email protected]

...

  assemble_beta_apk_with_firebase:
    <<: *android_config
    environment:
    steps:
      - *checkout_code
      - *android_dependencies
      - run:
          name: Clean old APK's
          command: |
            cd workspace/App
            ./gradlew clean
      - run:
          name: Install Firebase CLI
          command: |
            curl -sL firebase.tools | bash
      - run:
          name: Build beta APKs and upload to Firebase App Distribution
          command: |
            cd workspace/App
            bundle exec fastlane android distribute_branch_with_temp_version_name branch_name:${CIRCLE_BRANCH}`
      - jira/notify:
          environment_type: testing
          job_type: deployment

...

Expected behavior

Orb version

circleci/[email protected]

What happened

the build number is always 1 and always has just one build record (just with updated last update time) in Jira

I think the build number depends on ${CIRCLE_BUILD_NUM}, so tried to check it and it is working fine and has value 193

Attempt to get Jira Issues from https://circleci.com/api/v1.1/project/github/talabat-dhme/POSMiddleware/193 Job is passing, workflow is null Results from Jira: Success! { "acceptedBuilds": [ { "pipelineId": "POSMiddleware", "buildNumber": 1 } ], "rejectedBuilds": [], "unknownIssueKeys": [ "OPSC-812" ] }

Expected behavior

every Build should have a new number and add a new build record on JIRA

Orb version

orbs:
jira: circleci/[email protected]

What happened

I've a pipeline which is triggered when something is merged to develop.

When it happens we trigger a new workflow which tags a new version of our software.

As you can see, the flow is triggered on a specific tag.

And the jira_notify job is executed here:

That release include only one ticket which has been merged to develop, i.e. it's ABC-123 and that ticket name is included:

1. in the branch name which has been merged to develop
2. in one of the new commits merged to develop

This is the yml chunk where I've configured jira_notify:

      - base_checkout:
          name: Prod deploy
          post-steps:
            - jira/notify:
                environment_type: production
                job_type: deployment
                scan_commit_body: false

I've tried with both scan_commit_body = true and false.

Expected behavior

The ticket ABC-123 is marked as deployed on JIRA

Actual behavior

Orb version: 1.3.1

What happened

Based on our investigation the latest (1.3.1) as previous (1.3.0) version of this orb does not work together with alpine based docker images. Tested images: alpine:latest, hashicorp/terraform:latest

Working pipelines

jira:
    docker:
        -   image: cimg/base:stable
    steps:
        - jira/notify

Not working pipeline

jira:
    docker:
        -   image: alpine
    steps:
        - run: apk add --no-cache jq
        - run: apk add --no-cache curl
        - jira/notify

Error code

Curl failed with code 200. full response below.
{
  "name" : "James Bond",
  "login" : "agent007",
  "id" : "xxxxxx-xxxx-xxxx-xxxx-xxxxxx"
}

Today the orb hardcodes --arg description "${CIRCLE_PROJECT_REPONAME} #${CIRCLE_BUILD_NUM} ${CIRCLE_JOB}". I would love to override that with parameters that were specific to this deployment.

Hi

The CircleCI Jira integration https://marketplace.atlassian.com/apps/1215946/circleci-for-jira has not completed the Security Self-Assessment Program. See https://developer.atlassian.com/platform/marketplace/security-self-assessment-program.

Is it planned to complete the Security Self-Assessment Program for the CircleCI Jira integration?

Created from https://support.circleci.com/hc/en-us/requests/81565.

Orb version

N/A

What happened

N/A

Expected behavior

N/A

Orb version

1.3.1

What happened

Less of an error and more of a request. This orb only allows for a deployment to live in two states: success or failed. Jira itself on the deployments board has may more states and I would like to take advantage of. EG: deployment started, rollback, pending deployment, etc...

Expected behavior

Ideally, it is exposed as a parameter, enum I would guess, that allows a greater degree of flexibility. Do deployments with a blue/green deployment model with rollouts and it would be great to report the status more accurately.

Orb version

1.1.7

What happened

When a job fails, the "Update status in Atlassian Jira" step also fails:

The output inside the failing step ends with this:

environment: line 27: jq: command not found

Exited with code exit status 127
CircleCI received exit code 127

Jira is not updated with the failed build status.

It works as expected when the previous steps in the job all pass, this appears to only be an issue when running jira/notify after failed steps.

Expected behavior

Jira is updated with the failing build status

Orb version

When #32 is (was) merged, it added pending status when an approval is blocking the workflow.

this should be optimized to consider deployments specially.

• it should be possible to look forward and see if there is a gated deployment to send as "pending".

• in scenarios that this job is followed by approval (covered in #32)

• IF downstream job is setting deployment parameter (need to introspect config)

• THEN send final status for build side, and mark deployment as pending.

What happened

Expected behavior

Orb version

1.1.2

What happened

Build fails during install jq because of an API rate limit.

curl: (22) The requested URL returned error: 403 rate limit exceeded

My guess is that everyone who uses this orb is counting towards the rate limit for for api.github.com.

Expected behavior

Build should succeed, jq install script should not be hitting that API, maybe just lock the version for safety anyway?

Orb version

circleci/[email protected]

What happened

Was using the jira/notify command to mark a deployment for a service. The verify_api_key step fails due to the fetch function. A valid response of 200 is marked as a failure.

Here is the output of the Update status in Atlassian Jira step

200:https://circleci.com/api/v2/me?circle-token=****************************************
Curl failed with code 200. full response below.
{
  "name" : "my name",
  "login" : "username",
  "id" : "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx"
}

Exited with code exit status 1

Unable to link due to it being a private project.

Expected behavior

fetch should not error on a HTTP_200_OK response.

Orb version

1.3.1

What happened

Create a project token
Put it in CIRCLE_CI in a context
Add the orb to config.yml
Add a jira/notify step
The job fails with "You must log in first." after trying to curl https://circleci.com/api/v2/me?circle-token=${CIRCLE_TOKEN}

Expected behavior

The orb should work with project tokens.

It is insane to require personal tokens for an automated CI/CD job. What happens when I rotate my personal key? What happens when I leave the company? Do all our builds fail now?

Orb version

What happened

Expected behavior

Notification about Cicleci builds to Jira tickets by anyone in a team.

Orb version

1.0.2

What happened

1. I have the issue key saved in branch name ABC-123-test
   1. I don't really find it useful to repeat issue key name in my commit, but ok, I try:
2. I have a commit message with multiple lines, when issue key ABC-123is saved in the last line, so it looks like this:

   with multiple lines
   and issue key
   being in the last one (for clarity)
   ABC-123
   

3. The subject key in all_commit_details contains only the first line, so there's no way to extract the issue key
4. As the result I get the message at the end of CircleCI build:
   {"acceptedBuilds":[],"rejectedBuilds":[{"key":{"pipelineId":"XXX","buildNumber":1},"errors":[{"message":"At least one 'issueKeys' is required"}]}],"unknownIssueKeys":[]}Success!

Expected behavior

I would like the script to extract the data from branch key within all_commit_details first and then try subject (which should contain the entire commit message body).

Please let me know if there's anything to clarify!

Orb version

1.0.6

What happened

While deploying our new circle.yml configuration, the following sequence of builds happened:

1. Build for the pull request with our new Jira-notifying circle.yml, which failed due to some minor production-only differences in the deployment scripts.
2. Builds for a few subsequent commits that attempted to fix the failing build also failed.
3. A last commit was pushed and a build successfully ran.

Expected behavior

The tagged Jira issue IDs for all of the commits that deployed are sent to Jira via the Orb (e.g., all stories from steps (1), (2) and (3). (3) because it was the immediately deployed commit, and (1) and (2) because they were never successfully built, and this is the first deployment including those commits.

In the all_commit_details field of the build JSON, which the Orb inspects for issue keys, only the commits for the current build are provided. However, if there are previous failed builds, I would ideally expect to see the commits from the current build as well as all previously failed builds—back in time until the most recent green build on the same branch.

I don't know the CircleCI API well, so I can think of two possible issues:

1. The Orb needs to follow the chain of failed builds backwards to collect commits from the most recent passing build, or
2. The CircleCI API is supposed to present all of the commits present (since the last passing build) in all_commit_details, but this doesn't work when using the v1.1 API and workflows, because one job in the workflow might pass and another fail. (It's certainly the case that previous_successful_build points to a previous job in the workflow, even though the overall workflow failed.)

Is it the intended behavior that when a deploy notification is triggered, it should include information from all commits (since the previous passing build)?

Orb version

circleci/[email protected]

What happened

JIRA orbs fails unexpectedly:

Attempt to get Jira Issues from https://circleci.com/api/v1.1/project/github/<team>/<project>/44
jq: error (at <stdin>:2): Cannot iterate over null (null)
Exited with code 5

This issue seems to be about the same: https://discuss.circleci.com/t/jira-integration-failing-at-notify-command/31698

Expected behavior

Success run

Orb version

1.3.0

What happened

The Jira orb relies on a call to a CircleCI API v1.1 endpoint: https://circleci.com/api/v1.1/project/${VCS_TYPE}/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/${CIRCLE_BUILD_NUM} to get the commit details (all_commit_details object):

parse_jira_key_array () {
                      # must save as ISSUE_KEYS='["CC-4"]'
                      fetch https://circleci.com/api/v1.1/project/${VCS_TYPE}/${CIRCLE_PROJECT_USERNAME}/${CIRCLE_PROJECT_REPONAME}/${CIRCLE_BUILD_NUM} /tmp/job_info.json
                      # see https://jqplay.org/s/TNq7c5ctot
                      ISSUE_KEYS=$(cat /tmp/job_info.json | jq '[.all_commit_details[].subject | scan("(<<parameters.issue_regexp>>)")   | .[] ] + [.all_commit_details[].branch | scan("(<<parameters.issue_regexp>>)")   | .[] ] + [if .branch then .branch else "" end | scan("(<<parameters.issue_regexp>>)")  | . [] ] + [if <<parameters.scan_commit_body>> then .all_commit_details[].body else "" end | scan("(<<parameters.issue_regexp>>)")   | .[] ]')
                      if [ -z "$ISSUE_KEYS" ]; then
                        # No issue keys found.
                        echo "No issue keys found. This build does not contain a match for a Jira Issue. Please add your issue ID to the commit message or within the branch name."
                        exit 0
                      fi

However, since the move to "pipelines", all_commit_details is returned empty.

Expected behavior

Would it be possible to update the Jira orb so it uses API v2 endpoints instead? (“Get a pipeline by ID” or “Get a pipeline by number”)

Orb version

1.0.6

What happened

I have a config file with 2 workflows, both with jira/notify included on last job.
First workflow triggers the second workflow using pipeline API.
Both workflows complete successfully, but the status in JIRA is reported only for the first one.

In the second workflow, the step Update status in Atlassian Jira completes with:

Attempt to get Jira Issues from  https://circleci.com/api/v1.1/project/bitbucket/xxx/xxx/xxx
Job is passing, workflow is null
Results from Jira: 
No Jira keys associated with: [].
{
  "acceptedBuilds": [],
  "rejectedBuilds": [
    {
      "key": {
        "pipelineId": "wiremo",
        "buildNumber": 1
      },
      "errors": [
        {
          "message": "At least one 'issueKeys' is required"
        }
      ]
    }
  ],
  "unknownIssueKeys": []
}

Note: when accessing directly the CircleAPI to get the commit status, the field all_commit_details is empty for the second workflow. Because of this I guess it cannot find JIRA ticket ID.
This would be fixed in our case, if the orb is adjusted to scan not only the all_commit_details field but also the branch field.

Expected behavior

JIRA build status is updated for both workflows.