getRepoWorkflows Documentation

Purpose

The node is designed to interact with GitHub's API to retrieve workflow run data from a specified repository. It allows users to obtain information about workflows based on various parameters such as repository owner, repository name, event type, workflow status, and conclusions. This function serves as a critical component for analytics and data platform applications that require insights into GitHub Actions workflows, enabling better monitoring and management of CI/CD processes.

Settings

1. Owner

• Input Type: String
• Description: Specifies the owner of the GitHub repository. This can be either a GitHub user or an organization name. Changing this setting alters which repository's workflows are being retrieved.
• Default Value: octocat

2. Repo

• Input Type: String
• Description: Indicates the name of the repository to fetch workflow runs from. If this value is changed, the workflows fetched will correspond to the new repository specified.
• Default Value: Hello-World

3. Event

• Input Type: Enum (Dropdown)
• Description: Represents the GitHub event which triggers the workflow. Common events include push, pull_request, etc. Modifying this setting will filter the workflow runs returned based on the specified event.
• Default Value: GithubWorkflowEvents.PUSH (This is an imported constant that represents the "push" event.)

4. Status

• Input Type: Enum (Dropdown)
• Description: Denotes the workflow status to filter the results. Possible values include in_progress, completed, and queued. Altering this setting will change which workflows (based on their current state) are returned.
• Default Value: GithubWorkflowStatuses.COMPLETED (This is an imported constant that represents completed workflows.)

5. Conclusion

• Input Type: Enum (Dropdown)
• Description: Specifies the conclusion of the workflow, such as success, failure, or neutral. Changing this parameter will filter the workflow runs returned according to the specified outcome.
• Default Value: GithubWorkflowConclusions.SUCCESS (This is an imported constant that represents successful workflow conclusions.)

6. Page

• Input Type: Numeric
• Description: Indicates which page of results to return in paginated responses. Adjusting this will help you navigate through large datasets by specifying which page of results to fetch.
• Default Value: 1

7. Per Page

• Input Type: Numeric
• Description: Sets the number of workflow runs to return per request. A higher value could result in a single request returning more data, while a lower value will provide fewer results per page.
• Default Value: 30

How It Works

1. Input Handling: The function takes inputs through the parameters inputs, config, and context. Defaults are assigned based on provided configurations if inputs are unavailable.
2. Integration Setup: It builds a connection to the GitHub API using the utility function the integration connection. If the integration fails, the function will throw an error with an appropriate message.
3. Input Validation: It checks for the presence of required fields (owner, repo, event, and status) and throws an error if any are missing.
4. Data Retrieval: It calls the getWorkflowRuns method on the integration instance, passing the assembled parameters.
5. Output: Returns the fetched data in the format { "output1": outputData }. If there is an error during the API call, it returns an error object with a message indicating the failure.

Use Cases & Examples

Use Case 1: Monitoring CI/CD Execution

A development team wants to track the success and failure rates of their CI/CD workflows triggered by code pushes to maintain software quality.

Use Case 2: Reporting Workflow Statistics

An organization needs to generate weekly reports on workflow execution results, providing insights into the efficiency and reliability of their automated processes.

Use Case 3: Triggering Alerts

An automated system can utilize this function to trigger alerts when workflows fail, enabling timely interventions.

Example Configuration

To monitor the successful workflows triggered by pushes to a repository, the configuration might look like the following:

{
  "inputs": {
    "owner": "my-org",
    "repo": "my-repo",
    "event": "push",
    "status": "completed",
    "conclusion": "success",
    "page": 1,
    "perPage": 50
  },
  "config": {
    "owner": "default-org",
    "repo": "default-repo",
    "event": "push",
    "status": "completed",
    "conclusion": "success",
    "page": 1,
    "perPage": 30
  },
  "context": {}
}

In this example:

• The owner is set to my-org, indicating the organization that owns the repository.
• The repo is set to my-repo, specifying which repository's workflows should be fetched.
• The event, status, and conclusion are filtering results to only show successful workflow runs triggered by push events.
• Pagination settings ensure the user can view up to 50 results per page, starting from the first page of results.