-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR]: Also match on title
or partial body
content?
#4
Comments
as the goal of this action is to always return the 'last one', the limit must be 1 |
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 |
You can just take the first element? (unless performing additional filtering like this FR would involve)
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
Rather specific values, that don't really belong in an issue title or label, but can be useful metadata to match on. With the Real workflow examples - Click to viewAllowing 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: concurrency:
group: docs-pullrequest-${{ github.event.pull_request.number }}
cancel-in-progress: true And this one, although the - 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 }}
I presently don't need this right now, but if I do at a later point I'll give it a shot 👍 For now might be worth leaving the issue open to see if any other users want to express interest in the feature request? |
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 |
Presently from what I understand, this action works by:
issue_number
,is_closed
).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.
The text was updated successfully, but these errors were encountered: