-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Actions - Manually trigger a workflow/action #23668
Comments
This would be great. GitHub’s actions has a “on: workflow_dispatch” directive which enables a button in the UI to trigger it manually: 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. |
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: ...
|
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. |
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? |
When I say stages, I mean multiple of your equivalent of I have a quite complex workflow, that also uses 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!! |
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 |
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. The only reason I'm running manually at the moment is because |
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 my side i created a brand new repository
but I don't have any button to trigger the action (which has new ran before) |
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. Note also that |
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
1 similar comment
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
Please stop posting these |
For those who need a workaround, use |
Thanks for the suggestion for the The problem is that The entire CI process runs even if the action is 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. |
Any update ? |
Does |
Is there any API for triggering actions? |
Please follow #28163 |
fix #23668 My plan: * In the `actions.list` method, if workflow is selected and IsAdmin, check whether the on event contains `workflow_dispatch`. If so, display a `Run workflow` button to allow the user to manually trigger the run. * Providing a form that allows users to select target brach or tag, and these parameters can be configured in yaml * Simple form validation, `required` input cannot be empty * Add a route `/actions/run`, and an `actions.Run` method to handle * Add `WorkflowDispatchPayload` struct to pass the Webhook event payload to the runner when triggered, this payload carries the `inputs` values and other fields, doc: [workflow_dispatch payload](https://docs.github.com/en/webhooks/webhook-events-and-payloads#workflow_dispatch) Other PRs * the `Workflow.WorkflowDispatchConfig()` method still return non-nil when workflow_dispatch is not defined. I submitted a PR https://gitea.com/gitea/act/pulls/85 to fix it. Still waiting for them to process. Behavior should be same with github, but may cause confusion. Here's a quick reminder. * [Doc](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch) Said: This event will `only` trigger a workflow run if the workflow file is `on the default branch`. * If the workflow yaml file only exists in a non-default branch, it cannot be triggered. (It will not even show up in the workflow list) * If the same workflow yaml file exists in each branch at the same time, the version of the default branch is used. Even if `Use workflow from` selects another branch  ```yaml name: Docker Image CI on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' type: choice options: - info - warning - debug tags: description: 'Test scenario tags' required: false type: boolean boolean_default_true: description: 'Test scenario tags' required: true type: boolean default: true boolean_default_false: description: 'Test scenario tags' required: false type: boolean default: false environment: description: 'Environment to run tests against' type: environment required: true default: 'environment values' number_required_1: description: 'number ' type: number required: true default: '100' number_required_2: description: 'number' type: number required: true default: '100' number_required_3: description: 'number' type: number required: true default: '100' number_1: description: 'number' type: number required: false number_2: description: 'number' type: number required: false number_3: description: 'number' type: number required: false env: inputs_logLevel: ${{ inputs.logLevel }} inputs_tags: ${{ inputs.tags }} inputs_boolean_default_true: ${{ inputs.boolean_default_true }} inputs_boolean_default_false: ${{ inputs.boolean_default_false }} inputs_environment: ${{ inputs.environment }} inputs_number_1: ${{ inputs.number_1 }} inputs_number_2: ${{ inputs.number_2 }} inputs_number_3: ${{ inputs.number_3 }} inputs_number_required_1: ${{ inputs.number_required_1 }} inputs_number_required_2: ${{ inputs.number_required_2 }} inputs_number_required_3: ${{ inputs.number_required_3 }} jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: ls -la - run: env | grep inputs - run: echo ${{ inputs.logLevel }} - run: echo ${{ inputs.boolean_default_false }} ```   --------- Co-authored-by: TKaxv_7S <[email protected]> Co-authored-by: silverwind <[email protected]> Co-authored-by: Denys Konovalov <[email protected]> Co-authored-by: Lunny Xiao <[email protected]>
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
The text was updated successfully, but these errors were encountered: