Avoid creating duplicate issues

[expipiplus1]

It would be great to be able to avoid creating an issue when one with the same title already exists (optionally I suppose)

[peter-evans]

Hi @expipiplus1

Good idea. I'll look into adding this feature.

[expipiplus1]

Thank you!

[expipiplus1]

At the moment I'm doing something hacky like this:

    - id: check_issue
      if: ${{ failure() }}
      run: |
        issue_title=blah
        echo "::set-output name=issue_title::$issue_title"
        echo "::set-output name=create_issue::true"
        hub issue --state open --format $'%U %t\n' | grep -F "$issue_title" | while read u; do
          echo "Issue already exists: $u"
          echo "::set-output name=create_issue::false"
        done
      env:
        GITHUB_TOKEN: ${{ secrets.TUVOK_TOKEN }}

    - name: Create issue for failure
      if: ${{ failure() && steps.check_issue.outputs.create_issue == 'true' }}
      uses: peter-evans/create-issue-from-file@v2
      with:
        title: ${{ steps.check_issue.outputs.issue_title }}
        content-filepath: ~/issue_body
        token: ${{ secrets.TUVOK_TOKEN }}

[aisensiy]

#478 Add a PR to solve this.

[peter-evans]

@aisensiy Apologies for the slow response. I really appreciate the effort you've made to implement this feature. However, it's caused me to reconsider my initial intention to add the feature to this action. I think it would be much better to separate this functionality into a new action.

There is already precedent for this with two of my other actions, create-or-update-comment and find-comment. There are some examples here showing how they are used together.

I think GitHub actions work best when they do one job and do it well. Adding lots of functionality to one action should be avoided in my opinion. I also think separating the issue search functionality into a separate "primitive" action would allow it to be used in other situations, not just for this use case.

So my proposal is that we create a new action called find-issue that works in a similar way to find-comment. The issue-number output of that new action is fed into this action to update it. @aisensiy Would you be interested in creating/maintaining that action?

[aisensiy]

I think this is a better solution than mine and I'd like to have a try.

[micalevisk]

I've just created an action to find the last updated issue that has the given labels: https://github.com/marketplace/actions/find-last-issue

I tested it here: https://github.com/micalevisk/awesome-nestjs/issues/5 As you can see, the issue was updated by the bot thanks to this step:

      - name: Update last report open issue created
        if: ${{ steps.last_issue.outputs.has_found == 'true' }} ## <<<<
        uses: peter-evans/create-issue-from-file@v3
        with:
          title: Link checker report
          content-filepath: ./lychee-out.md
          issue-number: ${{ steps.last_issue.outputs.issue_number }} ## <<<<
          labels: |
            report
            automated issue

[polarathene]

I think GitHub actions work best when they do one job and do it well. Adding lots of functionality to one action should be avoided in my opinion.

I agree with that 👍

Better to have simpler maintainable actions that others can create composited actions of if they want to consolidate under one action.

---

@peter-evans what do you think of the find-last-issue action from @micalevisk ? If it serves the purpose well enough, it would be good to mention it to users in the README for this action?

If so it would be good to document with something like this:

name: 'Manually trigger action (for testing)'
on: workflow_dispatch

jobs:
  test-issue-management:
    name: 'Test - Issue Create + Update'
    runs-on: ubuntu-22.04
    permissions:
      contents: read
      issues: write
    env:
      issue-lookup-label: automated-issue
      issue-content: ${{ runner.temp }}/issue-content.md
    steps:
      # Permissions (contents: read)
      - uses: actions/checkout@v3

      - name: 'Example - Prepare issue body'
        run: |
          echo -e "Testing _issue_ **creation**.\nSHA: ${{ github.sha }}" > ${{ env.issue-content }}

      # Permissions (issues: read)
      - name: 'Look for an existing issue'
        id: last-issue
        uses: micalevisk/last-issue-action@v2
        # Find the last updated open issue with a `automated-issue` label:
        with:
          state: open
          labels: ${{ env.issue-lookup-label }}

      # Permissions (issues: write)
      - name: 'Create a new issue, or update an existing one'
        uses: peter-evans/create-issue-from-file@v4
        with:
          title: Test issue
          content-filepath: ${{ env.issue-content }}
          # Update an existing issue if one was found (issue_number),
          # otherwise an empty value creates a new issue:
          issue-number: ${{ steps.last-issue.outputs.issue_number }}
          # Add a label(s) that `last-issue` can use to find this issue,
          # and any other relevant labels for the issue itself:
          labels: |
            ${{ env.issue-lookup-label }}
            some-other-label-for-triage

It was not obvious that the two actions supported this create or update flow (that an empty output to an input was compatible/error-free to fallback to issue creation)

[kdeldycke]

Also had difficulties maintaining a single open issue to keep track of my broken links via lychee. Their dedicated action also advised on using peter-evans/create-issue-from-file. But it kept creating an infinite amount of issues at each workflow run.

Inspired by this thread, I ended up creating my own version. It is quite convoluted but does the job of:

• Reusing the previously open issue
• Closing duplicate issues
• Closing the previously open issue if broken links are fixed

All my code is available at: https://github.com/kdeldycke/workflows/blob/92b66c8b2059e22248eb9ceff6f67bb2b8dea542/.github/workflows/lint.yaml#L173-L266