Gitea Actions Workflow_dispatch
You set up gitea actions workflow_dispatch to trigger pipeline jobs by hand. This event lets engineers start a workflow from the web interface or API. Teams often use manual runs for database tasks, rollbacks, and hotfix releases. Still, broad repo roles often give too many people the power to run production jobs. A wide role lets any writer trigger strong runner keys on live servers. How gitea actions workflow_dispatch works in your pipelines Standard pipelines wait for code pushes or pull r
GitHub Actions Security + Agentic Workflow Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up gitea actions workflow_dispatch to trigger pipeline jobs by hand. This event lets engineers start a workflow from the web interface or API. Teams often use manual runs for database tasks, rollbacks, and hotfix releases. Still, broad repo roles often give too many people the power to run production jobs. A wide role lets any writer trigger strong runner keys on live servers.
How gitea actions workflow_dispatch works in your pipelines
Standard pipelines wait for code pushes or pull requests to start a job. Manual triggers change this flow so humans can pick the exact time to run. You define the event inside your workflow file on the default branch first. Once Gitea reads that file, it shows a run button in the web view. Engineers can pick the target branch and fill in custom form fields before starting.
These input fields let teams pass strings, choices, or true-or-false flags into the job. The runner machine reads these values and passes them to your shell scripts. Teams use these inputs to pick a target server or a release tag. The runner also gets access to repo secrets stored for that specific project. Then the runner logs into your cloud or database to do the work.
Managing inputs and branch rules for manual runs
Input forms make manual jobs much safer than raw shell scripts on laptops. You can set up drop-down lists so users do not type wrong server names. Still, the runner treats every input string as plain text during the run. If a script passes that input straight to a shell, bad commands can run. Teams must check every input value inside the job before running system commands.
Branch rules also shape how manual triggers behave across a busy software team. A user with write access can edit the workflow file on a test branch. Next, they can trigger a manual run from that same test branch right away. If your secrets are shared across all branches, that test job gets real keys. Teams should restrict secret scopes so only protected branches can read live keys.
GitHub Actions Security + Agentic Workflow Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native workflow roles solve and what they leave open
Gitea repo roles do a good job of gating who sees the run button. Read-only users cannot start manual jobs, while writers and admins can start them. Protected branch rules also stop unreviewed code from landing in your main branch. This setup handles basic team roles for small projects with low risk.
Yet repo roles leave a big gap once the job starts running commands. The role decides who clicks the button, not what the runner does next. Inside the job, the runner uses static keys with wide power over your systems. It might run a bad SQL query or read sensitive user tables by mistake. Native pipeline logs also show raw output unless you mask values by hand. If a job prints emails, phone numbers, card numbers, or national IDs, logs save them. You cannot pause a single risky command inside a running job for human review. You also cannot rewrite matched fields in query results before the runner sees them.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
Why is the manual run button missing in my repository?
The workflow file must exist on the default branch before Gitea shows the button. You also need write access to the repo to see and use the trigger.
Can I start a manual workflow from a feature branch?
Yes, once the workflow file is on the default branch, you can pick another branch. The branch picker in the web view lets you choose where the job runs.
How do I stop test branches from using production secrets during manual runs?
Do not store live keys as global repo secrets open to every branch. Split your live jobs into separate repos or restrict runners to protected branches only.