Actions - Manually trigger a workflow/action #10497

@ghnp5 commented on GitHub (Apr 25, 2023):

Hi @andysh-uk - yep, exactly.

I have several stages in the same yaml file, so I see multiple "re-run" buttons.

At the moment, I'm running one by one, but I'm hoping this will not be the long-term solution.

@ghnp5 commented on GitHub (Apr 25, 2023): Hi @andysh-uk - yep, exactly. I have several stages in the same yaml file, so I see multiple "re-run" buttons. At the moment, I'm running one by one, but I'm hoping this will not be the long-term solution.

GiteaMirror commented

@andysh-uk commented on GitHub (Apr 25, 2023):

Hi @ghnp5, when you say "stages" are these jobs or steps?

As you can see in my screenshot, I have several steps within a single job, so I only have one re-run button.

If you have several jobs, can you combine the steps of each job into one, so you also only have one re-run button, or is there a reason they need to be separate jobs, and not just steps within a single job?

@andysh-uk commented on GitHub (Apr 25, 2023): Hi @ghnp5, when you say "stages" are these jobs or steps? As you can see in my screenshot, I have several steps within a single job, so I only have one re-run button. If you have several jobs, can you combine the steps of each job into one, so you also only have one re-run button, or is there a reason they need to be separate jobs, and not just steps within a single job?

GiteaMirror commented

@ghnp5 commented on GitHub (Apr 25, 2023):

When I say stages, I mean multiple of your equivalent of Deploy-Website-Production:.

I have a quite complex workflow, that also uses strategy matrix, etc, so it would be very limiting/troublesome to be merging all into the same stage/job.

And we should not have to accommodate (or limiting ourselves) for something that should be an easy "fix" (to add a button to re-run all) 🙂 , hopefully!!

@ghnp5 commented on GitHub (Apr 25, 2023): When I say stages, I mean multiple of your equivalent of `Deploy-Website-Production:`. I have a quite complex workflow, that also uses `strategy matrix`, etc, so it would be very limiting/troublesome to be merging all into the same stage/job. And we should not have to accommodate (or limiting ourselves) for something that should be an easy "fix" (to add a button to re-run all) 🙂 , hopefully!!

GiteaMirror commented

https://docs.github.com/en/actions/using-workflows/reusing-workflows

@andysh-uk commented on GitHub (Apr 25, 2023):

Thanks @ghnp5 I thought it would be something more complex, but thought I'd check.

This is a first release so for (relatively) simple things, it works great. I've completely replaced my TeamCity instance with it. I use it for deploying web apps from Git to Linux servers over SSH, running deployments commands over SSH, building Go applications and publishing them straight to S3.

I don't know if this would work in Gitea or your scenario (and I have zero experience with GH Actions) but could you have a workflow that calls your other workflows as each step? So you'd have one "master" workflow with a single job, and multiple steps, that just calls your other ones, which you could then trigger?

@andysh-uk commented on GitHub (Apr 25, 2023): Thanks @ghnp5 I thought it would be something more complex, but thought I'd check. This is a first release so for (relatively) simple things, it works great. I've completely replaced my TeamCity instance with it. I use it for deploying web apps from Git to Linux servers over SSH, running deployments commands over SSH, building Go applications and publishing them straight to S3. I don't know if this would work in Gitea or your scenario (and I have zero experience with GH Actions) but could you have a workflow that calls your other workflows as each step? So you'd have one "master" workflow with a single job, and multiple steps, that just calls your other ones, which you could then trigger? https://docs.github.com/en/actions/using-workflows/reusing-workflows

GiteaMirror commented

2025-11-02 09:09:26 -06:00

@ghnp5 commented on GitHub (Apr 25, 2023):

Thanks. I might explore this more and more, as we go!

As soon as Actions was released, I went ahead and created this first Action (never worked with GH Actions before), and I already had a lot of challenges in the process, but glad I got it working at the end, anyway!

Well done to Gitea Developers who worked on this!

I'm giving them time, anyway, to slowly make the improvements we've all been suggesting.
Worst case scenario, I'll automate some "dummy commit" (increase a number in a file or so), to run everything manually.

The only reason I'm running manually at the moment is because schedule doesn't work yet, actually.

@ghnp5 commented on GitHub (Apr 25, 2023): Thanks. I might explore this more and more, as we go! As soon as Actions was released, I went ahead and created this first Action (never worked with GH Actions before), and I already had a lot of challenges in the process, but glad I got it working at the end, anyway! Well done to Gitea Developers who worked on this! I'm giving them time, anyway, to slowly make the improvements we've all been suggesting. Worst case scenario, I'll automate some "dummy commit" (increase a number in a file or so), to run everything manually. The only reason I'm running manually at the moment is because `schedule` doesn't work yet, actually.

GiteaMirror commented

@pangliang commented on GitHub (Aug 18, 2023):

Self-owned images are based on other image versions. When the dependent image releases a new version, I usually use this function to trigger a new build to use the new dependent version

on:  
    workflow_dispatch:  
        inputs:  
            ES_VER:  
                description: 'ElasticSearch Version'  
                required: true

ARG ES_VER  
FROM docker.elastic.co/elasticsearch/elasticsearch:${ES_VER}

@pangliang commented on GitHub (Aug 18, 2023): Self-owned images are based on other image versions. When the dependent image releases a new version, I usually use this function to trigger a new build to use the new dependent version ``` on: workflow_dispatch: inputs: ES_VER: description: 'ElasticSearch Version' required: true ``` ``` ARG ES_VER FROM docker.elastic.co/elasticsearch/elasticsearch:${ES_VER} ```

GiteaMirror commented

2025-11-02 09:09:26 -06:00

@nouknouk commented on GitHub (Aug 24, 2023):

When the dependent image releases a new version, I usually use this function to trigger a new build

On my side i created a brand new repository ops/test2, with one action .gitea/workflows/test.yml like below

name: GitHub Actions Demo
run-name: testing out GitHub Actions
on:  
    workflow_dispatch:  
        inputs:  
            ES_VER:  
                description: 'ElasticSearch Version'  
                required: true 
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job is now running on a ${{ runner.os }} server hosted by GitHub!"

but I don't have any button to trigger the action (which has new ran before)

@nouknouk commented on GitHub (Aug 24, 2023): > When the dependent image releases a new version, I usually use this function to trigger a new build On my side i created a brand new repository `ops/test2`, with one action `.gitea/workflows/test.yml` like below ``` name: GitHub Actions Demo run-name: testing out GitHub Actions on: workflow_dispatch: inputs: ES_VER: description: 'ElasticSearch Version' required: true jobs: Explore-GitHub-Actions: runs-on: ubuntu-latest steps: - run: echo "This job is now running on a ${{ runner.os }} server hosted by GitHub!" ``` but I don't have any button to trigger the action (which has new ran before) ![action page](https://github.com/go-gitea/gitea/assets/4757213/988d38db-fcd9-484b-afd6-7f90a843e62c)

GiteaMirror commented

2025-11-02 09:09:26 -06:00

@ghnp5 commented on GitHub (Aug 25, 2023):

Yeah, there's no way to manually trigger the action, yet.

Only if you have an automatic trigger based on changing the YAML file, etc.
There is a "Re-run all jobs", but not a "Create New Run" or equivalent.

Note also that workflow_dispatch is ignored on Gitea.

@ghnp5 commented on GitHub (Aug 25, 2023): Yeah, there's no way to manually trigger the action, yet. Only if you have an automatic trigger based on changing the YAML file, etc. There is a "Re-run all jobs", but not a "Create New Run" or equivalent. Note also that `workflow_dispatch` is ignored on Gitea.

GiteaMirror commented

@webvalera96 commented on GitHub (Oct 14, 2023):

yes, but i think this feature will be very cool

@webvalera96 commented on GitHub (Oct 14, 2023): yes, but i think this feature will be very cool

GiteaMirror commented

@ParadiseFallen commented on GitHub (Oct 16, 2023):

+1

@ParadiseFallen commented on GitHub (Oct 16, 2023): +1

GiteaMirror commented

@deurk commented on GitHub (Oct 17, 2023):

+1

@deurk commented on GitHub (Oct 17, 2023): +1

GiteaMirror commented

@bencurio commented on GitHub (Oct 17, 2023):

+1 🚀

@bencurio commented on GitHub (Oct 17, 2023): +1 🚀

GiteaMirror commented

2025-11-02 09:09:28 -06:00

@denyskon commented on GitHub (Oct 17, 2023):

Please stop posting these +1 messages, they don't help anyone. If you'd like something to be implemented, please use reactions to upvote the main issue, do not spam it with your comments. Everybody who contributes to Gitea does it voluntarily in their free time.

@denyskon commented on GitHub (Oct 17, 2023): Please stop posting these `+1` messages, they don't help anyone. If you'd like something to be implemented, please use reactions to upvote the main issue, do not spam it with your comments. Everybody who contributes to Gitea does it voluntarily in their free time.

GiteaMirror commented

@denyskon commented on GitHub (Oct 17, 2023):

For those who need a workaround, use on: issue_comment and create a specific issue where you'd comment to trigger a workflow run :)

@denyskon commented on GitHub (Oct 17, 2023): For those who need a workaround, use `on: issue_comment` and create a specific issue where you'd comment to trigger a workflow run :)

GiteaMirror commented

2025-11-02 09:09:28 -06:00

@bencurio commented on GitHub (Oct 18, 2023):

Thanks for the suggestion for the issue_comment action, I made a working example based on it.

The problem is that issue_comment triggers a CI JOB on all project related comments, so this is inefficient. To work around this, I put a filter condition on each job so that the job only starts if the comment is exactly !actions run build or !actions run test or !actions run all

The entire CI process runs even if the action is push or pull_request, or if the comment is !actions run all

Unfortunately, the CI process is triggered by every project comment, but quickly stops due to filtering.

name: Test
on:
  push:  
  pull_request:
  issue_comment:
    
jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request != '' || github.event.pusher != '' || github.event.comment.body == '!actions run build' || github.event.comment.body == '!actions run all' }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run
        run: |
          echo Tada!            
  test:
    name: Test
    runs-on: ubuntu-latest
    if: ${{ github.event.pull_request != '' || github.event.pusher != '' || github.event.comment.body == '!actions run test' || github.event.comment.body == '!actions run all' }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Run
        run: |
          echo Moaar test!

Starting CI job via API request:

$ curl -X 'POST' \
  'https://<<host>>/api/v1/repos/<<org>>/<<repo>>/issues/<<issue_id>>/comments?token=<<token>>' \
  -H 'accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
  "body": "!actions run all"
}'

Happy hacking.

@bencurio commented on GitHub (Oct 18, 2023): Thanks for the suggestion for the `issue_comment` action, I made a working example based on it. The problem is that `issue_comment` triggers a CI JOB on all project related comments, so this is inefficient. To work around this, I put a filter condition on each job so that the job only starts if the comment is exactly `!actions run build` or `!actions run test` or `!actions run all` The entire CI process runs even if the action is `push` or `pull_request`, or if the comment is `!actions run all` Unfortunately, the CI process is triggered by every project comment, but quickly stops due to filtering. ```yaml name: Test on: push: pull_request: issue_comment: jobs: build: name: Build runs-on: ubuntu-latest if: ${{ github.event.pull_request != '' || github.event.pusher != '' || github.event.comment.body == '!actions run build' || github.event.comment.body == '!actions run all' }} steps: - name: Checkout uses: actions/checkout@v4 - name: Run run: | echo Tada! test: name: Test runs-on: ubuntu-latest if: ${{ github.event.pull_request != '' || github.event.pusher != '' || github.event.comment.body == '!actions run test' || github.event.comment.body == '!actions run all' }} steps: - name: Checkout uses: actions/checkout@v4 - name: Run run: | echo Moaar test! ``` Starting CI job via API request: ```bash $ curl -X 'POST' \ 'https://<<host>>/api/v1/repos/<<org>>/<<repo>>/issues/<<issue_id>>/comments?token=<<token>>' \ -H 'accept: application/json' \ -H 'Content-Type: application/json' \ -d '{ "body": "!actions run all" }' ``` Happy hacking.

GiteaMirror commented

2025-11-02 09:09:28 -06:00

@scovillo commented on GitHub (Mar 2, 2024):

For those who would prefer another solution than the "issue_comment trigger", I make use of the "paths" feature.
Setup a folder in your project (e.g. "trigger"), which includes a file (e.g. "name-of-manual-ci-job") and is reserved for triggering the "manual" ci job.
For example:

Setup your job running on a specific paths event:

name: Release
on:
  push:
    branches:
      - main
    paths:
      - '.gitea/workflows/trigger/release'

You can also filter this event on other jobs:

name: Snapshot
on:
  push:
    branches:
      - main
    paths-ignore:
      - '.gitea/workflows/trigger/**'

To start a "manual" ci job via commit, just commit and push a modification of the referring ci job file in the trigger folder, e. g.

Hope this helps someone.

Thanks for the great work on gitea, I love it and use it for years!

@scovillo commented on GitHub (Mar 2, 2024): For those who would prefer another solution than the "issue_comment trigger", I make use of the "paths" feature. Setup a folder in your project (e.g. "trigger"), which includes a file (e.g. "name-of-manual-ci-job") and is reserved for triggering the "manual" ci job. For example: ![grafik](https://github.com/go-gitea/gitea/assets/130607437/bacd7e59-28d9-43dd-ac9a-adc29015248e) Setup your job running on a specific paths event: ``` name: Release on: push: branches: - main paths: - '.gitea/workflows/trigger/release' ``` You can also filter this event on other jobs: ``` name: Snapshot on: push: branches: - main paths-ignore: - '.gitea/workflows/trigger/**' ``` To start a "manual" ci job via commit, just commit and push a modification of the referring ci job file in the trigger folder, e. g. ![grafik](https://github.com/go-gitea/gitea/assets/130607437/a0c2eb27-64a5-4a48-8169-b6ea87c64ef4) Hope this helps someone. Thanks for the great work on gitea, I love it and use it for years!

GiteaMirror commented

@Sharaf5 commented on GitHub (Jun 21, 2024):

Any update ?

@Sharaf5 commented on GitHub (Jun 21, 2024): Any update ?

GiteaMirror commented

@akashkroy commented on GitHub (Jun 28, 2024):

Does workflow_run work ?

@akashkroy commented on GitHub (Jun 28, 2024): Does `workflow_run` work ?

GiteaMirror commented

@yinheli commented on GitHub (Jul 18, 2024):

Is there any API for triggering actions?

@yinheli commented on GitHub (Jul 18, 2024): Is there any API for triggering actions?

GiteaMirror commented