-
Notifications
You must be signed in to change notification settings - Fork 12
Github Actions
Last updated 24JUL25
This document provides a visual explanation of the GitHub Actions workflows used in this repository. Each workflow is represented by a Mermaid flowchart, followed by a brief description of its purpose and steps.
.github/ISSUE_TEMPLATE/agent_configuration_issue.yaml
This file is a GitHub Issue Template, not a workflow. It defines a structured form for users to fill out when reporting issues related to agent configuration. It uses a YAML-based form with fields for agent type, model provider, tools, deployment status, and detailed descriptions of the problem.
.github/ISSUE_TEMPLATE/bug_report.yaml
This is a GitHub Issue Template for reporting bugs. It provides a standard format including checks for existing issues, descriptions of current and expected behavior, steps to reproduce, and environment details. This ensures that bug reports are consistent and contain the necessary information for debugging.
.github/ISSUE_TEMPLATE/docs_update.yaml
This is a GitHub Issue Template for requesting changes to documentation. It helps users specify which part of the documentation is affected, the type of update needed (e.g., correction, clarification), and provides space for proposed changes.
.github/ISSUE_TEMPLATE/feature_request.yaml
This is a GitHub Issue Template for suggesting new features. It guides the user to articulate the problem statement, a proposed solution, any alternatives, a user story, and acceptance criteria. This structured approach helps in evaluating and implementing new features.
.github/ISSUE_TEMPLATE/tool_integration_issue.yaml
This is a GitHub Issue Template for reporting problems with tool integrations (e.g., Gofannon, custom tools). It collects specific information like the tool type, name, repository, configuration, and error messages, which is crucial for troubleshooting integration issues.
.github/scripts/collect_metrics.py
This Python script is the engine behind the metrics collection workflow. It uses the PyGithub library and direct GraphQL calls to the GitHub API to gather a wide range of repository statistics. Its key tasks are to fetch basic data like stars and forks, calculate recent activity such as new issues and PRs, retrieve traffic data including views and clones, fetch discussion metrics, and finally aggregate all data into a Pandas DataFrame before saving it as a Parquet file.
.github/scripts/update_version.py
This is a helper script used by the release workflow. Its purpose is to programmatically update a public/version.json file. It takes a SemVer version number as an argument, validates it, and writes it to the JSON file along with the current UTC timestamp as the buildDate.
Path: .github/workflows/collect_metrics.yml
Description: This workflow runs daily or on manual trigger to collect a comprehensive set of repository metrics. It runs a Python script to gather data like stars, forks, traffic, and recent activity, saves the data to a Parquet file, and uploads it to an AWS S3 bucket for analysis and storage. It also uploads the file as a GitHub artifact for easy debugging.
flowchart TD
A[Start] --> B{Trigger};
B -->|Schedule: Daily at 00:00| C[Job: collect-and-upload-metrics];
B -->|Manual: workflow_dispatch| C;
subgraph "Job: collect-and-upload-metrics"
C --> D[1. Checkout Code];
D --> E[2. Setup Python];
E --> F[3. Install Dependencies];
F --> G[4. Configure AWS Credentials];
G --> H[5. Run collect_metrics.py Script];
H --> I[6. Upload Parquet to S3];
I --> J[7. Upload Parquet as Artifact];
end
J --> K[End];
Path: .github/workflows/create-release.yml
Description: This workflow automates the process of creating a new software release. It is triggered manually and requires a new version number as input. The workflow updates the version.json file, commits this change, and then creates a corresponding Git tag and a GitHub Release with auto-generated release notes.
flowchart TD
A[Start] --> B(Manual Trigger with Version Input);
subgraph "Job: cut-release"
B --> C[1. Checkout Code];
C --> D[2. Setup Python];
D --> E[3. Run update_version.py Script];
E --> F[4. Configure Git];
F --> G[5. Commit & Push version.json];
G --> H[6. Create GitHub Release & Tag];
end
H --> I[End];
Path: .github/workflows/deploy-functions.yml
Description: This workflow handles the manual deployment of backend services to Firebase Functions. It sets up the complete environment, including Node.js and Python, authenticates with Google Cloud, prepares environment variables and secrets, and then runs the Firebase CLI to deploy only the functions.
flowchart TD
A[Start] --> B(Manual Trigger: workflow_dispatch);
subgraph "Job: deploy_functions"
B --> C[1. Checkout Repo];
C --> D[2. Setup Node.js & Python];
D --> E[3. Install Firebase CLI];
E --> F[4. Create Config & Extract Project ID from Secret];
F --> G[5. Authenticate to Google Cloud];
G --> H[6. Prepare Python venv & Install Deps];
H --> I[7. Create .env file from Secrets];
I --> J[8. Deploy to Firebase Functions];
J --> K[9. Cleanup Config File];
end
K --> L[End];
Path: .github/workflows/deploy-my-fork.yml
Description: This workflow is designed for individual forks of the repository. It allows a developer to deploy their version of the frontend application to their own Firebase Hosting project. It is triggered manually, builds the project, and deploys to a specified hosting channel (live or a preview channel). It includes crucial checks to ensure the necessary Firebase secrets are configured in the forked repository.
flowchart TD
A[Start] --> B(Manual Trigger with Branch & Channel ID);
subgraph "Job: build_and_deploy_fork"
B --> C[1. Checkout Branch];
C --> D[2. Create Firebase Config & Extract Project ID];
D --> E{Secrets & Project ID OK?};
E -->|No| F[Fail with Error Message];
E -->|Yes| G[3. npm install & npm run build];
G --> H[4. Deploy to Firebase Hosting];
end
F --> I[End];
H --> I[End];
Path: .github/workflows/sync-upstream.yml
Description: This workflow helps keep a fork synchronized with the main upstream repository. It is triggered manually with an upstream tag and a new branch name. It fetches the specified tag, merges it into the new branch, and automatically resolves any merge conflicts by preferring the local (fork's) changes. This is useful for pulling in upstream updates without overwriting custom modifications.
flowchart TD
A[Start] --> B(Manual Trigger with Upstream Tag & New Branch Name);
subgraph "Job: sync-upstream"
B --> C[1. Checkout Repo with PAT];
C --> D[2. Configure Git & Add Upstream Remote];
D --> E[3. Verify Upstream Tag Exists];
E --> F[4. Create New Local Branch];
F --> G[5. Attempt to Merge Upstream Tag];
G --> H{Merge Conflicts Exist?};
H -->|Yes| I[Resolve Conflicts by keeping Local Version];
H -->|No| J[6. Commit Merge];
I --> J;
J --> K[7. Push New Branch to Fork];
end
K --> L[End];
Path: .github/workflows/upstream-pr-checks.yml
Description: This workflow is intended to run basic checks like linting and testing on pull requests submitted to the main repository. Currently, the pull_request trigger is disabled, so it only runs when triggered manually. It checks out the PR's code, installs dependencies, and runs the defined lint and test scripts.
flowchart TD
A[Start] --> B{Trigger};
B -->|Manual: workflow_dispatch| C[Job: lint_and_test];
B -->|PR (disabled)| C;
subgraph "Job: lint_and_test"
C --> D[1. Checkout PR Code];
D --> E[2. Setup Node.js];
E --> F[3. Install Dependencies];
F --> G[4. Run Linter];
G --> H[5. Run Tests];
end
H --> I[End];