Tracking deployments has limited functionality

[vedrani]

Tracking of GH deployments and transforming them to Jira deployments is limited and it's leaking Jira into Github VSC:

• Parse only Jira key from commit message
  • Leaks Jira app rules into commit message guidelines and forcing change of commit message guidelines
• Doesn't analyse GH Deployment payload field or other GH deployment fields

All that results in stiff and strict solution for tracking deployments.

Instead Jira App for GH should parse Jira keys from:

• PR connected to commit
  • PR title
  • PR body
• GH deployment payload field
  • This would allow engineers to inject Jira keys manually in CI adding flexibility and robustness to it considering we are running GHA in various cases

Simplest solution would be just to add here also deployment.payload

jiraIssueKeyParser(`${deployment.ref}\n${message}\n${allCommitsMessages}\n${deployment.payload}`),

And we would have capability to inject Jira keys from outside in flexible way without requirement to change commit messages to contain Jira key.

[mhanley00]

I second this! Any updates here? In the meantime, any suggestions for alternative intermediary solutions other than putting all issue numbers in the commit? I see in the Jira docs deployments are not expected to work with merge commit PRs but it seems like not that long ago this was a feature, this would really, really help automate our workflow #855

[aareman]

Thanks @vedrani for submitting this issue. This is something that has affected us.

We use Trunk Based Development with one feature branch per jira ticket. Tickets are linked via the branch name, but deployments don't track merged branch names. We don't put jira keys into the commit messages. Therefore we can't get the deployments to show up in jira. We use Github actions to deploy and run ci jobs, but haven't been able to get them to show up in jira as deployments except with putting issue keys in commits.

I'm going to experiment further with the gh deploy action as recommended in the docs here, but I ran into limitations with it in the past and the ability to inject explicit deploy key information would be clutch. (Also just having it pull from the branch name that was merged would be helpful too, though the on push master/main event wouldn't have the branch name.)

[aareman]

After some experimentation I was able to get it to work by using pull_request_target. Here is my working example. I only had the ticket id in the branch name, not in the commit messages or pr title/body.

name: Deploy to prod

on:
  pull_request_target:
    types: [closed]
    branches:
      - master
  

jobs:
  cd:
    name: Deploy to Production
    runs-on: ubuntu-latest
    permissions:
      deployments: write
      contents: read
    if: github.event.pull_request.merged == true
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up environment
        env:
          MERGED_BRANCH: ${{ github.event.pull_request.head.ref || '' }}
        run: |
          echo "MERGED_BRANCH=$MERGED_BRANCH" >> $GITHUB_ENV

      - name: Print merged branch name
        run: |
          echo "Merged branch: ${{ env.MERGED_BRANCH }}"

      - uses: chrnorm/deployment-action@v2
        name: Create GitHub deployment
        id: deployment
        with:
          token: "${{ github.token }}"
          ref: ${{ github.event.pull_request.head.ref || '' }}
          environment-url: https://testurl
          environment: production

      - name: Update deployment status (success)
        if: success()
        uses: chrnorm/deployment-status@v2
        with:
          token: "${{ github.token }}"
          environment-url: ${{ steps.deployment.outputs.environment_url }}
          deployment-id: ${{ steps.deployment.outputs.deployment_id }}
          state: "success"

      - name: Update deployment status (failure)
        if: failure()
        uses: chrnorm/deployment-status@v2
        with:
          token: "${{ github.token }}"
          environment-url: ${{ steps.deployment.outputs.environment_url }}
          deployment-id: ${{ steps.deployment.outputs.deployment_id }}
          state: "failure"

[aareman]

Update: This workaround is not robust enough since the "ref" has to exist in the repo. We have a separate repo that controls setting up various environments, and the refs don't exist there. We can create a dummy ref, but that is a hack. @vedrani your suggested change to the codebase above would solve our problem completely.