GitHub

Overview#

Read and write issues and pull requests in repositories you connect.

Use this block when its responsibility is clear in the graph. Give it a name that describes the work it performs, then test it with representative input before publishing.

Setting it up#

You never see anyone's GitHub sign-in, and you do not need your own GitHub account to build with this step. People who run the workflow connect their own account and approve exactly what it may do before it starts.

Actions#

• Create an issue - Opens a new issue in the selected repository. Makes a change. Needs: Title. Optional: Description, Labels. People running it are asked to allow: _Create issues in the repository they choose_.
• Comment on an issue - Adds a comment to an existing issue or pull request. Makes a change. Needs: Issue number, Comment. People running it are asked to allow: _Comment on issues in the repository they choose_.
• Open a pull request - Opens a pull request between two branches that already exist. Makes a change. Needs: Title, From branch, Into branch. Optional: Description, Open as draft. People running it are asked to allow: _Open pull requests in the repository they choose_.
• List issues - Reads issues from the selected repository. Only looks things up. Optional: Which issues, Only with labels, Maximum issues. People running it are asked to allow: _Read issues in the repository they choose_.
• List pull requests - Reads pull requests from the selected repository. Only looks things up. Optional: Which pull requests, Maximum pull requests. People running it are asked to allow: _Read pull requests in the repository they choose_.
• Search issues - Finds issues in the selected repository matching words you give it. Only looks things up. Needs: Look for. Optional: Which issues, Maximum issues. People running it are asked to allow: _Search issues in the repository they choose_.
• Add labels to an issue - Labels an existing issue or pull request. Makes a change. Needs: Issue number, Labels. People running it are asked to allow: _Label issues in the repository they choose_.

Which repository it acts on#

• The person running picks a repository - the default, and the right choice for anything you publish. They choose one of their own repositories before the run starts.
• Always this repository - fixed to one you name. Use it for a workflow only you will run.
• Any repository they allow - reaches every repository their connection covers. They see a clear warning, and the run gets a lower limit on actions.

Filling in the fields#

Every field can be filled three ways: type it (a fixed value), from a step (a value an earlier step produced - pick it from a list, no paths to type), or text + steps (fixed text with values from earlier steps woven in). The panel shows what will be sent, using sample data, and tells you before you publish if a field is missing or points at a step that is no longer connected.

Trying it#

Test runs from the canvas use sample GitHub data. Nothing reaches a real account until someone runs the published workflow with their own connection.

Working examples#

These are complete starting points, not decorative diagrams. Every graph is also available in the main template library and is checked by the workflow compiler.

1. Bug report to GitHub issue#

You will build: A filed issue in the repository the runner chose, with a link back.

The person running it connects their own GitHub and picks the repository, so the issue lands where they expect. The run cannot start until they authorize it, and a crash mid-write reconciles instead of filing a duplicate.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

2. Weekly issue digest#

You will build: A readable summary of what changed, from real issues.

Reading needs no write permission, so the consent screen stays narrow. Reads are safe to retry, so a transient GitHub outage never loses the run.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

3. Triage comment on an open issue#

You will build: A comment added to the issue the runner named.

Commenting keeps the discussion where the team already works. The comment is reconciled after an interruption, so a retry never posts twice.

Open this template and adapt the labels, prompts, or credentials to your own workflow.

Ports#

• Input: Input (in): any, optional, multi_object.
• Output: Success (success): object, optional, single.
• Output: Error (error): object, optional, single.

Inspector#

• Action panel: choose what the step does, which account resource it acts on, and where each field's value comes from. See _Setting it up_ above.

Behavior#

• Input requirement: Choose an action. Fields can come from earlier steps or be typed in.
• Execution: Runs through the Edgaze Gateway, which talks to the provider on the runner's behalf.
• Timeout: 30000 ms by default (1000 to 120000 ms).

Cost#

Uses outbound HTTP transport and may contribute to the run's compute cost.

Security#

• The person running the workflow connects their own account and approves exactly what this step may do before the run starts. The workflow never holds their sign-in, and you never see it.
• Actions that make changes are listed separately on the approval screen, and the run is limited to the account resources the person chose.

Retry#

If a step is interrupted mid-change, Edgaze checks with the provider whether the change went through before ever trying again, so nothing is posted or created twice.

Production checklist#

• Test the happy path and one malformed or empty input.
• Keep credentials out of prompts and published graph configuration.
• Set a timeout and retry policy that matches the operation's side effects.
• Name the final result so a runner can tell what success looks like.