Add more unique deployment names

[fullstackzach]

trafficstars

Hi - I was wondering if there was some way to customize the "Deployment" or "Pipeline" fields to show more unique information? Or, if an improvement could be made?

Deployments for our team can mean deploying multiple components separately. A frontend, backend, poller/worker service, etc.

In this screenshot you can see that they currently just show "deploy". But, this isn't too useful since I don't know which is which. Once you click the underlying link it will actually take you to the GitHub action, where you can actually determine which belongs to which. It would be nice to map one of these fields to the name of the deploy instead.

Digging into the code here; I suspect this is where they are mapped. deployment.task I suspect resolves to the value deploy for displayName. But, I'm not too sure what to change in my github action, since it doesn't seem we specify that anywhere.

[rachellerathbone]

Hey @fullstackzach. Would this feature help? https://github.com/atlassian/github-for-jira/blob/main/docs/deployments.md#environment-mapping

[fullstackzach]

Hi @rachellerathbone - I did see that documentation when I was trying to solve this problem, but I don't think it solves my request.

Our deployments are being properly captured as "production" - as seen above, so environment mapping isn't the issue.

So for example the first item in the table above the GitHub action might be named "Deploy Frontend", and the second item is "Deploy Backend", but only "deploy" appears in Jira - it's not until I click the link that it takes me to Github and I see the name of the component in the Github UI

[thombergs]

Hey @fullstackzach,

can you give us a sample of your GitHub Actions workflow file so we can have a look?

[fullstackzach]

Sorry it took me a bit to get back to you here. I am a little apprehensive about posting our build config in a public forum, while giving you enough to work with. I inserted <redacted> where there is some items I do not want to share.

jobs:
  bump_version:
    name: Bump Version
    if: ${{ github.event_name == 'push' }}
    runs-on: [self-hosted, linux, aws]
    outputs:
      git_tag: ${{ steps.tag_version.outputs.new_tag }}
    steps:
    - name: Bump version and push tag
      id: tag_version
      uses: mathieudutour/[email protected]
      with: <redacted>

  build-<redacted>:
    name: Build <redacted> Docker image
    needs: bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  build-<redacted>:
    name: Build <redacted> Docker image
    needs: bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  build-<redacted>:
    name: Build <redacted> Docker image
    needs: bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  build-frontend-uat:
    name: Build Frontend Docker image for UAT
    needs: bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  build-frontend-staging:
    name: Build Frontend Docker image for Staging
    needs:
      - deploy-<redacted>-uat
      - deploy-<redacted>-uat
      - deploy-<redacted>-uat
      - deploy-<redacted>-uat
      - bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  build-frontend-production:
    name: Build Frontend Docker image for Production
    needs:
      - deploy-<redacted>-staging
      - deploy-<redacted>-staging
      - deploy-<redacted>-staging
      - deploy-<redacted>-staging
      - bump_version
    runs-on: [self-hosted, linux, aws]
    outputs:
      ecr-image-url: ${{ steps.build-tag-push-ecr.outputs.ecr-image-url }}
    steps:
    - uses: actions/checkout@v2
    - name: Build Tag Push Docker image to ECR
      id: build-tag-push-ecr
      uses: ./.github/actions/build-tag-push-docker
      with: <redacted>

  deploy-<redacted>-uat:
    name: Deploy <redacted> to UAT
    needs: 
      - build-<redacted>
      - bump_version
    environment: uat
    runs-on: [self-hosted, linux, aws]
    concurrency: deploy-<redacted>-uat
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to ECS
        uses: ./.github/actions/deploy-to-ecs-v2
        with: <redacted>

  deploy-<redacted>-uat:
    name: Deploy <redacted> to UAT
    needs:
      - build-<redacted>
      - bump_version
    environment: uat
    runs-on: [self-hosted, linux, aws]
    concurrency: deploy-<redacted>-uat
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to ECS
        uses: ./.github/actions/deploy-to-ecs-v2
        with: <redacted>

  deploy-<redacted>-uat:
    name: Deploy <redacted> to UAT
    needs:
      - build-<redacted>
      - bump_version
    environment: uat
    runs-on: [self-hosted, linux, aws]
    concurrency: deploy-<redacted>-uat
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Deploy to ECS
        uses: ./.github/actions/deploy-to-ecs-v2
        with: <redacted>

[shanegiroux]

Just popping in to add support on figuring out how to adjust those columns. Just spent a couple hours wondering if I was missing something obvious :)

[dt-atkinson]

Perhaps the deployment payload (on creation) can be used for these extra details if we have unique keys that can be looked up?

For example your deployment could easily have a pipeline and deployment key string added there, possibly nested under a jira info key?

[benoittgt]

Same for us. We would like to provide more informations. We have multiple location for production env for example, and they are not deployed at the same time. Custom name in "Deployment" column or "pipeline" column could be very useful.

Same for pre-production env who is not a testing env for us.

Deployment Status API from Github already accept custom naming.

I think Jira integration should accept only /production/i, /staging/i, and /testing/i and /dev(elopment)?/i and leave other env open and do not mark them as undefined (similar to https://github.com/atlassian/github-for-jira/issues/594).

But first maybe display more infos from the Github deployment status API. :)

Also

Just popping in to add support on figuring out how to adjust those columns. Just spent a couple hours wondering if I was missing something obvious :)

I think the doc should better explain how fields are mapped between Github API and Jira. I am not using Github Action to generate deployment and deployment status on Github API and it means lot's of digging to find the mapping.

Perhaps the deployment payload (on creation) can be used for these extra details if we have unique keys that can be looked up?

Also the "description" field should be display. But yeah payload is also a good one. You could provide additionnal informations dedicated for Jira deployment page.

[bgvozdev]

https://github.com/atlassian/github-for-jira/pull/1732

[benoittgt]

Hello

Ok after diging a little bit. I think the current implementation is good but it needs some documentation and maybe the field "deployment" should print another info. Few ideas:

• the commit (similar to https://github.com/atlassian/github-for-jira/pull/1732)
• the description of "deployment"
• Even better the description of the "deployment status".

For all those ideas "Deployment" should not have a link, but env should be mapped to environment_url (https://docs.github.com/en/rest/deployments/statuses#create-a-deployment-status)

With the existing implementation, to change the content of deploy and pipeline simply specify in Github Action the name of the task.

I do not use Github Action, but I was able to make this with the proper API calls on Github API.

[benoittgt]

I open two pull requests with changes based on url and description. Open for discussions.

• https://github.com/atlassian/github-for-jira/pull/1737
• https://github.com/atlassian/github-for-jira/pull/1736

[benoittgt]

Some changes have been pushed. You can see them already in Jira. I added some feedbacks on the PR directly. https://github.com/atlassian/github-for-jira/pull/1732#issuecomment-1318315308

[fullstackzach]

I looked at that PR and I agree with you @benoittgt, that the last commit message is not useful and that description would be a better choice and more useful. In our case our repo is a mono-repo, so our latest commit doesn't make sense since different components are deployed from that one repo.

[bgvozdev]

Hey @benoittgt @fullstackzach thanks for contributing. I agree with your thoughts and would also prefer it. Let's see what @kaganatlassian2 is thinking :)

[kaganatlassian2]

Hi @benoittgt @fullstackzach ,

We've updated the displayName to the latest commit message since the GitHub Actions is also using a similar approach while displaying their Workflow runs, iteratively we're planning to put the workflow run number in case it exists.

I can understand your point about using GitHub API but the thing is not all of our customers just use GitHub API for creating deployments there are also others who use GitHub Actions as well and for those, these values are always static and make no difference, and are indistinguishable at our end.

[kaganatlassian2]

@benoittgt @fullstackzach

For multi-environment deployments maybe what we can do is add a prefix that indicates the current environment information with the latest commit information. How's that sound?

[benoittgt]

Hello @kaganatlassian2 :)

since the GitHub Actions

I think the Jira integration should be closer to Github Deploy+Deployment API rather than a Github Action not maintained by Github itself. For example I am thinking about using this https://github.com/chrnorm/deployment-action/blob/6e62572161cddc34701816e65b5539572ff80325/action.yml#L24-L26 It is then used in deployment and deployment status Github API call. An example of a config for the deplyment Github Action.

name: Deploy
on: [push]
jobs:
  deploy:
    name: Deploy my app
    runs-on: ubuntu-latest
    permissions:
      deployments: write
    steps:
      - uses: actions/checkout@v1
      - uses: chrnorm/deployment-action@v2
        name: Create GitHub deployment
        id: deployment
        with:
          token: '${{ github.token }}'
          task: 'deploy:${{ github.event.repository.name }}'
          environment: us-production
          description: '${{ github.event.head_commit.message }}'

Result can be seen here: https://github.com/benoittgt/ga_deploy_test/actions/runs/3524913964/jobs/5910951556

It returns the last commit, but also a custom task name based on repository, and a custom env name. The custom task name will be displayed in Jira as a replacement for "deploy".

Result from the API.

l think this proposal should be looked at again : https://github.com/atlassian/github-for-jira/pull/1737 😄

[benoittgt]

For multi-environment deployments maybe what we can do is add a prefix that indicates the current environment information with the latest commit information. How's that sound?

For that we do one deployment per env. So we do not need something different. In rare case we add the env in the deploy task name (review app), but grouping them ins testing is good enough. :)

[benoittgt]

We are still looking for this feature. Our QA use a lot the deployment page and having correct links will help a lot. :)