I am trying to implement a GitHub Actions workflow that automatically labels an issue as "blocked" if it has dependencies on tasks that are still in progress. The action should be triggered when an issue is opened, edited, or reopened. Technical solution:
- Create a YAML file in the
.github/workflows
directory of the repository. - The workflow should be triggered on issue events: opened, edited, and reopened.
- Use the GitHub CLI tool to fetch the state of dependent issues.
- Use jq to parse and filter JSON data.
- If a dependent issue is found to be open, label the current issue as "blocked".
So far I have
Created file
label-blocked-issues.yml
in.github/workflows
:name: Label Blocked Issues on: issues: types: [ opened, edited, reopened ] jobs: label-blocked-issues: runs-on: ubuntu-latest steps: - name: Checkout Repository uses: actions/checkout@v3 - name: Install jq run: sudo apt-get -y install jq - name: Find and Label Blocked Issues id: find-blocked-issues run: | body=$(jq -r .issue.body $GITHUB_EVENT_PATH) dependencies=$(echo "$body" | grep -oE "#[0-9]+" | sed 's/#//g' || true) found_blocked=false for issue in $dependencies; do status=$(curl -s -H "Authorization: Bearer $GITHUB_TOKEN" \ -H "Accept: application/vnd.github.v3+json" \ "https://api.github.com/repos/${{ github.repository }}/issues/$issue" | jq -r .state) if [ "$status" != "closed" ]; then echo "Issue #$issue is still open" found_blocked=true fi done if [[ "$found_blocked" == true ]]; then echo "::set-output name=blocked::true" fi - name: Label Issue as Blocked if if: steps.find-blocked-issues.outputs.blocked == 'true' run: | echo "Labeling issue as blocked..." echo "GitHub Repository: ${{ github.repository }}" echo "Issue Number: ${{ github.event.issue.number }}" # Use the GitHub REST API to add the 'blocked' label curl -X POST \ -H "Accept: application/vnd.github.v3+json" \ -H "Authorization: Bearer ${{ secrets.GITHUB_TOKEN }}" \ -d '{"labels": ["blocked"]}' \ "https://api.github.com/repos/${{ github.repository }}/issues/${{ github.event.issue.number }}/labels" || true
Created file
test-event.json
within same directory:{ "action": "opened", "issue": { "number": 1, "title": "Test Issue", "body": "Depends on #123", "state": "open" } }
Tested steps from file
label-blocked-issues.yml
together withtest-event.json
using Nektos/Act tool with Act Command:act -e .github/workflows/test-event.json -s GITHUB_TOKEN="github_pat_11BDU************" -j label-blocked-issues -W .
All steps runs and passed successfully, except of the last one "Label Issue as Blocked if", when this step runs I get the following output:
[Label Blocked Issues/label-blocked-issues] ⭐ Run Main Label Issue as Blocked if [Label Blocked Issues/label-blocked-issues] docker exec cmd=[bash --noprofile --norc -e -o pipefail /var/run/act/workflow/3] user= workdir= | Labeling issue as blocked... | GitHub Repository: treasure-house-of-projects/skarb-ngo | Issue Number: 1 | { | "message": "Not Found", | "documentation_url": "https://docs.github.com/rest/issues/labels#add-labels-to-an-issue" | } [Label Blocked Issues/label-blocked-issues] ✅ Success - Main Label Issue as Blocked if [Label Blocked Issues/label-blocked-issues] Cleaning up container for job label-blocked-issues [Label Blocked Issues/label-blocked-issues] Job succeeded
Is there a specific reason why the issue label command might not be recognized despite having the correct version of GitHub CLI? Why all the time I faced with:
{
| "message": "Not Found",
| "documentation_url": "https://docs.github.com/rest/issues/labels#add-labels-to-an-issue"
| }
I have tried:
- Verified GitHub CLI version (2.4.0+dfsg1) in the workflow.
- Attempted to use the gh issue label command, but encountered the error.
- Open the link that appears in my output, and read the documentation, checked code samples for "Add labels to an issue" for cURL and GitHub CLI.
Make sure the following:
At first I was struggling to reproduce this problem, trying on Github Actions directly I had no issues. With the Act tool it worked too, until I changed
number
in the test-event.json to an issue that does not exist, only then did I get the error you mentioned. Using a token without access to a private repository also produces this behavior.