Running GitHub actions from a command-line on a self hosted runner

Hi,

I have a self hosted runner on my Ubuntu machine and would like to know if I can trigger GitHub actions from a command line. The purpose is to debug workflow.yml which is pushed to the repo but prefer not to make iteration of push to the branch just for debugging this file. Is there a good approach in debugging?

Thanks,
manoaman

@manoaman,

You can consider using the repository_dispatch event to do that:

  1. Add the “repository_dispatch” to the on key in your workflow.
on:
  repository_dispatch:
    types: [. . .]
  1. Execute the “Create a repository dispatch event” API on your local machine to trigger the workflow.
pat="<GitHub personal access token>"
base64AuthInfo='$pat | base64 -e'

curl --location --request GET \
--url 'https://api.github.com/repos/myOrg/myRepo/dispatches' \
--header 'Authorization: $base64AuthInfo' \
--header 'Accept: application/vnd.github.everest-preview+json' \
--header 'Content-Type: application/json' \
--data-raw '{
  "event_type": "test-repository-dispatch",
  "client_payload": {
    "unit": false,
    "integration": true
  }
}'
1 Like

Hi brightran,

Thanks for helping me out. I tried curl and getting not found error. Should API point to my server or api.github.com ? I tried both and latter is the error I’m getting. How do I construct correct url?

{
“message”: “Not Found”,
“documentation_url”: “https://developer.github.com/v3
}

Thank you,
manoaman

@manoaman,

Please try this:

curl --location --request POST \
--url 'https://api.github.com/repos/myOrg/myRepo/dispatches' \
--header 'Authorization: token <GitHub-personal-access-token>' \
--header 'Accept: application/vnd.github.everest-preview+json' \
--header 'Content-Type: application/json' \
--data-raw '{
  "event_type": "test-repository-dispatch",
  "client_payload": {
    "unit": false,
    "integration": true
  }
}'

I have tested it on my local machine and in the workflow, it can work as expected.
In addition, the request method is “POST”, not “GET”, I seem made a mistake in my above reply.

I tried with “POST” and changed “myOrg”, “myRepo”, ", and I am still getting the following error. Any thoughts on where I can reconfigure?

{
“message”: “Not Found”,
“documentation_url”: “https://developer.github.com/v3/repos/#create-a-repository-dispatch-event
}

One thing I realized in my “organization” tab is that I’m not belonging to any organization at this moment. So I’m not sure if I’m constructing a correct url. Do I need to create an organization and transfer account to that newly created organization?

How do I list the candidates I have for “myOrg” and “myRepo” from an API?

@manoaman,

No, you do not need to create a new organization.
Here are few points you need to understand:

  1. If your repository is in your Personal user account, you just replace “myOrg” with the name of the user account, and replace “myRepo” with the name of your repository.
    For example, I have a repository name “TestOutputs”, and it is in my personal user account “BrightRan”. When executing some APIs for this repository, the prefix of the request URL should be “https://api.github.com/repos/BrightRan/TestOutputs/xxx”.

  2. If your repository is in your Organization account, replace “myOrg” with the name of the organization account, and replace “myRepo” with the name of your repository.

  3. In addition, if you use Postman to execute the API, you need to navigate to “Authorization” tab, then select “Basice Auth” type and enter your GitHub personal access token in “Password” textbox. Generally, similar settings also are on the client of other API tools.

  4. Make sure the personal access token you are using has the required scopes that can trigger the workflows, I usually use the PAT that has the full access. You can see here to view more info.

If the problem still exists, please share the detailed steps and configurations you have done, so that we can check more detailed info to analyze the root cause.

hi brightran,

I granted full access to PAT and tried both Postman and cURL this time. And this is the response from Postman.

{
“message”: “Invalid request.\n\nFor ‘links/0/schema’, nil is not an object.”,
“documentation_url”: “https://developer.github.com/v3/repos/#create-a-repository-dispatch-event
}

For details, I have a snippet of my workflow.yml as…

name: Test workflow

env:
BUILD_DIRECTORY: “${{ github.workspace }}/folder1”

on:
repository_dispatch:
types: [opened, deleted]
push:
branches: [ master, development ]
pull_request:
branches: [ master, development ]

jobs:
build_and_test:
runs-on: self-hosted
steps:
- uses: actions/checkout@v2
- name: Show directory contents
run: |
ls
working-directory: ${{ env.BUILD_DIRECTORY }}
# More steps after this…

deploy:
runs-on: self-hosted
needs: build_and_test
if: github.ref == ‘refs/heads/master’
steps:
- name: Deploy app
run: exit 0

entered the following information in GUI…

URL…

POST: https//api.github.com/repos/{username}/{reponame}/dispatches

headers…
Accept: application/vnd.github.everest-preview+json
Content-type: application/json

authorization…

username: {username}
password: {github_token}

(breaking into two replies since one post only allows me to put two URLs.)

I also tried cURL and this did not provide me any response. Although, I’m not seeing new action in GitHub Actions tab.

curl --location --request POST
–url ‘https://api.github.com/repos/xxx/xxx/dispatches
–header ‘Authorization: token xxx’
–header ‘Accept: application/vnd.github.everest-preview+json’
–header ‘Content-Type: application/json’
–data-raw ‘{
“event_type”: “test-repository-dispatch”,
“client_payload”: {
“unit”: false,
“integration”: true
}
}’

Any thoughts? I’d be happy to provide more details if you can point me where.

Thanks,
manoaman

One more thing to add. Does PAT (Personal Access Token) needs to be added in either workflow.yml or the Secretes in targeted repo?

@manoaman,

I noticed you set the activity types of the repository_dispatch event as opened and deleted.

on:
  repository_dispatch:
    types: [opened, deleted]

When you execute the API, you also need to set the activity type (event_type) to be one of them, so that the workflow can be triggered.

. . .
"event_type": "opened",
. . .

OR

. . .
"event_type": "deleted",
. . .

About the PAT, if you wants to use the PAT in some steps in the workflow, you’d better set the PAT as a secrete in the repository, and then call the PAT from the secretes when run the workflows in the repository.

1 Like

@brightran
oh, how can I miss that. I had the wrong type in my request and I am seeing an event triggered.
But there is still a question remains which is my original purpose. How do I make changes to a workflow file without commit and push to GitHub? The goal is to debug workflow file.

@manoaman,

A workflow run is based on an existing ref (branch, tag, SHA) on the GitHub repository, and the run is generated according to the configurations defined in the workflow file on that ref.
GitHub is not able to read a workflow file from the local repository to generate the workflow run.

If you want to test the changed workflow, you need to push the new changes from the local repository to the remote GitHub repository. At least, you must push the modified workflow file to the remote.

If you want to directly run the workflow on your local machine according the modified workflow file on the machine, I think it is very hard:

  1. GitHub has some build-in features/services that can interpret/translate the YAML file and then tell the runner machine what commands need to be executed. You can’t run the workflow in the local repository, unless you can almost completely simulate the related features/services of GitHub.

  2. Simulating the related features/services of GitHub to interpret/translate the YAML file is quite complex. If you also try to translate the YAML file as some executable scripts on the machine by yourself, it is also not an easy thing.

  3. If some secrets are needed in the workflow, you almost have no methods to simulate creating and storing secrets in the repository. Similarly, it’s hard to simulate the contexts and GitHub’s default environment variables for the workflow.

  4. There also are some other technical barriers.

Depending on what you’re doing necktos/act might help…
I certainly use it to test changes to workflow files.