[FR]: Also match on `title` or partial `body` content?

[polarathene]

Presently from what I understand, this action works by:

• Mandatory label(s) to identify an issue + optional issue state.
• Only if a match is found will some outputs be set (issue_number, is_closed).
• Query to Github REST API is limited to one result (an issue/PR that has the requested labels + state), and is the last updated match.

---

Is there a reason for limiting the results to 1 (_from the default 30)?

With more results, the action could be used with a common label to get the issue_number for various automated issues. Doing a regex match on the title (eg: a prefix or suffix identifier), or body content (hidden content via comment is possible, great for storing metadata like an ID) would help better filter automated issues?

No immediate need for this additional filtering. Labels can mostly be used for the same thing, it's just polluting the label selection UI for issues/PRs with manual triage with labels. The more automated labels added, the more noise added there.

Using labels + state filters and sorting by last updated is still great to ensure a match, I'm just concerned about scaling.

[micalevisk]

Is there a reason for limiting the results to 1

as the goal of this action is to always return the 'last one', the limit must be 1

[micalevisk]

I like the match on title one

Feel free to submit a PR to implement that (as a another optional filter)

I'd use javascript generators so we can have a paginated iteration on all the issues

[polarathene]

as the goal of this action is to always return the 'last one', the limit must be 1

You can just take the first element? (unless performing additional filtering like this FR would involve)

---

I like the match on title one

Body is also nice. If it wasn't clear you can have a comment such as this:

<!-- last-issue-action-metadata: id=workflow-run-key-with-id-num-42 priority=high -->

I have two examples below, where that id value could be something like:

• docs-pullrequest-${{ github.event.pull_request.number }}
• ${{ github.event.workflow_run.head_sha }}

Rather specific values, that don't really belong in an issue title or label, but can be useful metadata to match on.

With the <!-- --> comment syntax, the content does not visually appear in the body text (only if you edit the body will you see it in markdown view).

Real workflow examples - Click to view

Allowing the workflow to inject some data relevant to the context of a run, eg with some workflows for PRs, I have a dynamic concurrency id so that whenever a PR is updated it will invalidate a lengthy workflow run early and start again (_the older run is redundant at this point_), those also have separate workflows that run due to security permissions with third-party contributors so that we can use secrets when necessary (_which doesn't run the contributor PR code_) and uses similar dynamic metadata to exchange artifacts for a PR workflow run: ```yaml concurrency: group: docs-pullrequest-${{ github.event.pull_request.number }} cancel-in-progress: true ``` And this one, although the `env.PR_HEADSHA` comment (sourced from an artifact retrieved earlier in the job) is probably referring to the later 2nd commit status job usage, to ensure it's not stuck on pending status if the earlier step to restore ENV from the triggering workflow run failed: ```yaml - name: 'Commit Status: Set Workflow Status as Pending' uses: myrotvorets/set-commit-status-action@1.1.5 with: token: ${{ secrets.GITHUB_TOKEN }} status: pending # Should match `env.PR_HEADSHA` when triggered by `pull_request` event workflow, # Avoids failure of ENV being unavailable if job fails early: sha: ${{ github.event.workflow_run.head_sha }} context: 'Deploy Preview (pull_request => workflow_run)' # ... - name: 'Commit Status: Update deployment status' uses: myrotvorets/set-commit-status-action@1.1.5 # Always run this step regardless of job failing early: if: ${{ always() }} env: DEPLOY_SUCCESS: Successfully deployed preview. DEPLOY_FAILURE: Failed to deploy preview. with: token: ${{ secrets.GITHUB_TOKEN }} status: ${{ job.status == 'success' && 'success' || 'failure' }} sha: ${{ github.event.workflow_run.head_sha }} context: 'Deploy Preview (pull_request => workflow_run)' description: ${{ job.status == 'success' && env.DEPLOY_SUCCESS || env.DEPLOY_FAILURE }} ```

---

Feel free to submit a PR to implement that (as a another optional filter)

I'd use javascript generators so we can have a paginated iteration on all the issues

I presently don't need this right now, but if I do at a later point I'll give it a shot :+1:

For now might be worth leaving the issue open to see if any other users want to express interest in the feature request?

[micalevisk]

You can just take the first element?

Right. As of now, there's no reason to fetch more because the filtering part is done by GitHub thus the first one will always be the right one that the action will return. Then we can improve the performance a bit by not fetching the others

---

I don't need those feature thus I won't implement that soon because that will require us to implement the filtering part (in case of title or body matching) by ourselves. Leaving this open so people could give it a shot