Closed dil-dvinnai closed 2 years ago
Thanks for the report! I've just release v1.2.0 with a fix for this. The issue is that the event.json
file is static once the job starts. I've added a check to see if GITHUB_TOKEN
is set, and if so it will query the API for live information rather than using the event.json
file.
You can use it like so:
- uses: mheap/github-action-required-labels@v1
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
with:
mode: exactly
count: 1
labels: "semver:patch, semver:minor, semver:major"
You can continue to use mheap/github-action-required-labels@v1
as the tag has been updated to point to v1.2.0
- all you need to do is provide the GITHUB_TOKEN
to use
Thanks, Michael, it works as expected!
When mheap/github-action-required-labels@v1 is used in a multi-step workflow, it won't detect label changes from previous steps, causing the condition of having at least 1 label fail. Steps to replicate the issue:
1) Setup files in the repo.
release-drafter/release-drafter@v5.15.0
is capable of automatically labeling pull request based on certain criteria, e.g. taking it from the branch prefix, likefeature/JIRA-123
-> because of feature prefix, labeling it asenhancement
.github/workflows/pr-label-enforcer.yaml:
.github/release-drafter.yml:
2) Submit a PR from e.g.
feature/JIRA-123
branch.mheap/github-action-required-labels@v1
adds the labelenhancement
, the second step sleeps for 15 seconds, still,release-drafter/release-drafter@v5.15.0
fails with an error of not finding any labels. Unfortunately, this causes the workflow to fail on every PR open, because the label checker will fail, and then have to be triggered again manually to pass. The use case of this whole automation would be to enforce labels in all PRs, but also automatically tag PRs when possible.