GitHub workflow
The GitHub backend allows you to trigger GitHub workflows for your self-service actions and automations, using Port's GitHub application.
The GitHub backend is available for both the standard Port GitHub app, and the self-hosted version.
![](/img/self-service-actions/portGithubWorkflowArchitecture.png)
The steps shown in the image above are as follows:
- Port publishes an invoked
action
message to a topic. - A secure topic (
ORG_ID.github.runs
) holds all the action invocations. - A listener implemented in Port's GitHub application receives the new topic message and runs the GitHub workflow defined by the creator of the self-service action/automation.
An example flow would be:
- A developer asks to deploy a new version of an existing
Microservice
, using a self-service action. - The
create
action is sent to thegithub.runs
topic. - Port's GitHub application event handler is triggered by this new action message.
- Port's GitHub application triggers the GitHub workflow that deploys a new version of the service.
- As part of the workflow, the new microservice
Deployment
is reported back to Port. - When the workflow is done, Port's GitHub application reports back to Port about the status of the action run (
SUCCESS
orFAILURE
), according to workflow's status.
A workflow triggered using the workflow_dispatch
trigger is self-contained. This means its actions and effects over the repository cannot trigger other automatic workflows.
- A developer invokes a "provision new microservice in monorepo" workflow.
- The workflow opens a new PR in the target repository based on a pre-defined template.
- The repository also has a workflow which is automatically triggered using the
on: pull_request: types: "opened"
trigger. - In this instance, the automatic PR workflow will not be triggered.
Configuration
When using this backend, you need to provide the GitHub organization and repository where the workflow is located, as well as the workflow name.
The workflow must reside in the repository's .github/workflows/
directory.
Automatic workflow status update
Additionally, you can define whether or not Port should automatically use the workflow's end status (SUCCESS
/FAILURE
) to update the action/automation status in Port.
By default, this is set to true
. To disable this option, set the reportWorkflowStatus
field to true
in the invocationMethod
object, or set the Report workflow status
option to No
if using the UI.
Examples
For complete examples of self-service actions using a GitHub workflow as the backend, check out the guides section.
Additional examples can be found in our action examples Github repository.