Actions - Manually trigger a workflow/action

[ghnp5]

Feature Description

Hey!

It would be very nice if we could have a button here to trigger a specific workflow/action:

So that I could trigger a job quickly, without having to push or waiting for a schedule.

Thanks!!

Screenshots

No response

[andysh-uk]

This would be great. GitHub’s actions has a “on: workflow_dispatch” directive which enables a button in the UI to trigger it manually:

https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow#running-a-workflow

However I have found in Gitea, if you navigate to an action that ran, there is a “re-run” button you can use to trigger it again.

[ghnp5]

However I have found in Gitea, if you navigate to an action that ran, there is a “re-run” button you can use to trigger it again.

This seems to be for single steps, only.

Unfortunately, there doesn't seem to be a way to re-run the whole workflow, unless I push a change.

[andysh-uk]

This seems to be for single steps, only.

Unfortunately, there doesn't seem to be a way to re-run the whole workflow, unless I push a change.

This button works for a job I believe: a job being an entry in the .yaml file with multiple steps.

In mine, all my steps are in a single job within the same .yaml file, so clicking the re-run button runs all steps in the job (workflow).

If you have each step in separate jobs, or separate .yaml files, then you'd need to combine them into the same job I guess.

name: Build and deploy andysh.uk website to the production environment.
on:
    push:
        branches: [ main ]
jobs:
    Deploy-Website-Production:
        runs-on: gitea-main
        env:
...
        steps:
            - name: Event information
              env:
                  EVENT_CONTEXT: ${{ toJSON(github.event) }}
              run: echo $EVENT_CONTEXT
            - name: Check out repository
              uses: actions/checkout@v3
              with:
                  ref: main
            - name: Install Composer dependencies
              run: composer install --no-interaction --prefer-dist --optimize-autoloader
            - name: Deploy assets to CDN
              run: ...
            - name: Deploy web files
              run: ...
            - name: Post-deployment configuration
              run: ...
            - name: Sync assets to local CDN replica
              run: ...

[ghnp5]

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.

[andysh-uk]

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?

[ghnp5]

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!!

[andysh-uk]

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

[ghnp5]

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.

[pangliang]

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} 

[nouknouk]

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)

[ghnp5]

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.

[denyskon]

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]

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

[bencurio]

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.

[scovillo]

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!