GitHub and Gmail integration

Mobile App Build Time Hotspot Tracker - Gradle/CocoaPods Analyzer Alerting This workflow automates the monitoring and analysis of CI/CD build performance for mobile projects using Gradle and CocoaPods. It triggers upon build completion, compares metrics against historical performance stored in Airtable, and leverages AI to identify regressions. The system provides automated feedback via GitHub PR comments and email alerts for critical performance drops. ⚡ Quick Implementation Steps Configure CI Pipeline: Set your CI job to send a POST request with build metrics to the workflow's Webhook URL. Set Configuration: Adjust the regressionThreshold (default: 20%) and excludeModules in the Set Configuration node. Connect Airtable: Link your credentials to the Fetch Historical Builds and Store Build Data nodes. Connect GitHub & Gmail: Authenticate your GitHub and Gmail OAuth2 credentials for reporting. Verify AI Model: Ensure the OpenAI Chat Model is connected to power the performance analysis. What It Does The workflow acts as an intelligent performance gatekeeper for development pipelines: Metric Collection: Captures detailed task durations, build IDs, and PR context directly from CI/CD webhooks. Historical Comparison: Automatically retrieves the last 10 builds for a specific repository to calculate average baselines. AI-Powered Diagnostics: Uses a specialized AI agent to analyze slowdowns, identify root causes, and provide optimization recommendations. Automated Reporting: Categorizes findings by severity (Critical, Warning, Info) and updates stakeholders through PR comments and high-priority emails. Who’s It For Mobile Engineering Teams looking to prevent "death by a thousand cuts" in build time slowdowns. DevOps/Platform Engineers who need automated auditing of build infrastructure health. Release Managers requiring an audit trail of performance regressions across different pull requests. Technical Workflow Breakdown Entry Points (Triggers) Webhook: Listens for POST requests at /webhook/build-hotspot-tracker containing build metrics and repository metadata. Processing & Logic Set Configuration: Defines static variables like regression sensitivity and modules to ignore (e.g., test modules). Historical Analysis: Aggregate nodes calculate min, max, and average build times from historical records. AI Build Analyzer: An AI Agent utilizing GPT-4.1-mini to synthesize current build data with historical trends and PR context. Route by Severity: A switch node that directs the workflow based on whether the AI classifies the regression as Critical, Warning, or Info. Output & Integrations GitHub (Comment on PR): Posts a formatted markdown report including a severity badge, regressions list, and root causes. Airtable (Store Build Data): Logs the build ID, total duration, and AI recommendations for long-term tracking. Gmail (Notify Email): Sends immediate alerts to the team for critical regressions, including a direct link to the affected PR. Customization Adjust Sensitivity Modify the regressionThreshold in the Set Configuration node to change how aggressive the system is in flagging slowdowns (e.g., set to 10 for stricter monitoring). Module Filtering Update the excludeModules parameter to ignore specific tasks like linting or unit tests that may have volatile durations but do not represent core build performance. Analysis Detail The AI Build Analyzer prompt can be customized to focus on specific platform needs, such as focusing heavily on CocoaPods link times or Gradle configuration phases. Troubleshooting Guide | Issue | Possible Cause | Solution | | :-------------------------- | :----------------------------------------- | :----------------------------------------------------------------------------------------- | | No PR Comments | GitHub permissions or incorrect PR number. | Verify your GitHub token has write access and the CI payload includes a valid prNumber. | | Historical Data Missing | Airtable Filter failure. | Ensure the repository and prNumber fields in Airtable match the incoming Webhook data. | | AI Analysis Errors | OpenAI credits or model timeout. | Check your OpenAI API quota and verify the gpt-4.1-mini model is available in your region. | | Emails Not Sending | Gmail OAuth2 expired. | Re-authenticate the Gmail node in your n8n credentials settings. | Need Help? If you need assistance customizing this workflow, adding new features or integrating more systems (like JIRA, Slack or Google Sheets), feel free to reach out. Our n8n automation experts at WeblineIndia are here to support you in scaling your automation journey.

How It Works Aggregates communication data from Slack, Microsoft Teams, Gmail, GitHub, and Confluence into a single, unified AI-powered analysis workflow designed for quality review and automated documentation updates. This solution is specifically aimed at teams managing distributed content and knowledge workflows across multiple platforms. It addresses the challenges of fragmented communication and isolated information silos that often prevent rapid content review and timely decision-making. The workflow begins with a scheduled trigger, followed by multi-source data collection, merging and normalizing inputs, Claude AI-powered analysis, validation and quality checks, formatting, and finally publishing updates to Notion and Confluence, accompanied by Slack notifications to ensure stakeholders are promptly informed. Setup Steps -Connect credentials: Slack API, Teams, Gmail OAuth, GitHub PAT. -Confluence API, Anthropic API key, Notion Integration. -Configure monitored channels/repositories. -Set schedule frequency. -Map output destinations (Notion/Confluence). -Test merged output before enabling automation. Prerequisites Slack workspace, Teams account, Gmail access, GitHub repository, Confluence space, Anthropic API key, Notion workspace, n8n instance. Use Cases Content review teams processing feedback, documentation teams aggregating updates, QA teams reviewing communications Customization Add/remove source nodes, adjust Claude prompts for analysis type, modify output destinations Benefits Saves 6+ hours weekly, eliminates missed content, AI-driven quality assurance

iOS Environment Config Sync Wizard: .env to Xcode This workflow automatically detects changes to .env.staging files, compares them against iOS Xcode configuration files, creates pull requests to sync values, and invalidates Xcode build caches when needed. It ensures consistency between environment files and iOS project configs while automating the propagation of changes across the codebase and notifying the team via email. Quick Implementation Steps Import the workflow JSON into your n8n instance Set up credentials for GitHub and email Configure the webhook URL in your Git repository Customize configuration parameters in the "Set Configuration" node Activate the workflow What It Does The Environment Config Sync for iOS Xcode Projects workflow is designed to maintain consistency between environment configuration files and iOS project configuration files. When changes are made to .env.staging, the workflow automatically detects these changes, determines which iOS configuration files need to be updated, creates a new branch with those updates, and opens a pull request for review. The workflow analyzes the differences between the environment file and iOS configs, identifies which values need to be synchronized, and applies these changes to the appropriate files. It also checks if any of the changed values require cache invalidation and handles this automatically. Finally, it sends a detailed email notification to the iOS team with information about the sync operation. This automation reduces manual work, ensures consistency between configuration files, and helps prevent issues caused by mismatched environment settings across different parts of the iOS build system. Who's It For This workflow is ideal for: iOS development teams managing environment-specific configurations DevOps engineers responsible for maintaining Xcode project configuration consistency Mobile app developers working with multiple environment configurations Teams implementing CI/CD best practices for iOS applications Organizations using environment files to manage build-time configurations for Xcode projects Requirements n8n instance (self-hosted or cloud) GitHub repository with iOS project files Email service (SMTP) for sending notifications .env.staging file or similar environment configuration file iOS configuration files (Info.plist, Config.xcconfig, etc.) How It Works Webhook Trigger: The workflow starts when a push event occurs in the GitHub repository Configuration Setup: Sets up configurable parameters for file paths, branches, and notification settings File Change Detection: Checks if the .env.staging file was modified in the push Config Diff Analysis: Compares the .env.staging file with iOS Xcode configurations to identify differences Branch Creation: Creates a unique branch name and creates a new branch in the repository File Update Preparation: Prepares the updated content for each configuration file File Updates: Updates each configuration file in the new branch with the synced values PR Creation: Creates a pull request with all the configuration changes Cache Invalidation: Invalidates Xcode build cache if necessary based on changed keys Email Notification: Sends a detailed email notification about the completed sync operation How To Set Up Steps to Configure and Use 1\. Import the Workflow Import the provided JSON file into your n8n instance 2\. Set Up Credentials GitHub**: Create a new credential with a GitHub personal access token with repo scope Email**: Create a new credential with your SMTP server details for sending emails 3\. Configure GitHub Webhook Go to your GitHub repository settings Navigate to Webhooks and click "Add webhook" Set the Payload URL to the webhook URL from your n8n workflow Select "application/json" as the content type Choose "Let me select individual events" and select "Push events" Click "Add webhook" 4\. Configure Parameters Modify the parameters in the "Set Configuration" node to match your project structure: envFilePath**: Path to your environment file (default: ".env.staging") configFiles**: Array of iOS config files to update (default: \["Info.plist", "Config.xcconfig"\]) targetBranch**: Branch to create PRs against (default: "main") cacheInvalidationKeys**: Keys that trigger cache invalidation (default: \["API\_KEY", "BUNDLE\_VERSION", "ENVIRONMENT"\]) prLabels**: Labels to apply to created PRs (default: \["config-sync", "automated", "ios"\]) emailTo**: Email address for notifications (default: "[email protected]") 5\. Configure Email Settings In the "Send Email Notification" node, update the "fromEmail" parameter to match your sending email address Ensure your SMTP credentials are properly configured in n8n 6\. Activate the Workflow Once all configurations are complete, activate the workflow Test by making a change to your .env.staging file and pushing it to the repository How To Customize Add More Config Files**: Update the configFiles parameter in the "Set Configuration" node to include additional iOS configuration files like .xcconfig files or project.pbxproj Modify Cache Invalidation Logic**: Update the cacheInvalidationKeys parameter to change which keys trigger cache invalidation Customize PR Content**: Edit the "Create PR" node to modify the PR title, body, or labels Change Email Notifications**: Update the "Send Email Notification" node to modify the email format, subject, or add additional recipients Implement Actual Cache Invalidation**: Modify the "Invalidate Cache" node to implement actual Xcode cache invalidation logic for your CI/CD system Add More Environment Files**: Extend the workflow to monitor additional environment files beyond .env.staging Add‑ons Multi-Environment Support: Extend the workflow to handle multiple environment files (.env.development, .env.production) with different target branches and configurations Configuration Validation: Add validation steps to ensure that environment values match expected formats or patterns before creating PRs Automated PR Merging: Add logic to automatically merge PRs if all checks pass and no conflicts are detected Configuration History Dashboard: Integrate with a database to track configuration changes over time and provide analytics Team Approval Workflow: Add approval steps that require team members to review and approve configuration changes before PRs are created Use Case Examples API Key Rotation: When security policies require rotating API keys, the workflow automatically updates all iOS configuration files with the new keys and invalidates the Xcode build cache to ensure the changes take effect immediately. Environment Promotion: When promoting configurations from staging to production, the workflow ensures that all iOS project files are consistently updated across the codebase, preventing deployment issues caused by mismatched configurations. Bundle Version Updates: When updating bundle versions in .env.staging for a new App Store release, the workflow automatically updates version strings in Info.plist files, ensuring version consistency for App Store submission. Feature Flag Management: When feature flags are added or modified in .env.staging, the workflow propagates these changes to Config.xcconfig files, ensuring that feature flags are consistently available throughout the iOS application. Multi-Target Projects: In projects with multiple iOS targets (e.g., app, extension, watchOS), the workflow can be extended to update configuration files across all targets when environment variables change, ensuring consistency throughout the application ecosystem. Troubleshooting Guide | Issue | Possible Cause | Solution | | --- | --- | --- | | Webhook not triggering | Webhook URL not configured correctly in GitHub | Verify the webhook URL is correctly copied and configured in your GitHub repository settings | | Changes not detected | .env.staging file path doesn't match configuration | Check the envFilePath parameter in the "Set Configuration" node and ensure it matches your file structure | | Branch creation fails | GitHub token doesn't have sufficient permissions | Ensure the GitHub personal access token has the "repo" scope and access to the target repository | | File updates fail | Config file paths don't exist in the repository | Verify the configFiles parameter in the "Set Configuration" node matches actual file paths in your repository | | PR creation fails | Target branch doesn't exist or insufficient permissions | Verify the targetBranch parameter matches an existing branch and the GitHub token has appropriate permissions | | Email notifications not sent | Email credentials not configured or incorrect | Verify your SMTP credentials are correctly configured in n8n and the email address in the "Send Email Notification" node is valid | | Cache invalidation not working | Cache invalidation logic not implemented for your CI/CD system | Modify the "Invalidate Cache" node to implement the appropriate Xcode cache invalidation mechanism for your CI/CD system | | PRs created with no changes | Diff logic not properly detecting differences | Review the "Perform Config Diff" node and ensure it correctly identifies differences between environment and iOS config files | | Workflow stops after file change detection | Workflow logic error in code nodes | Check the JavaScript code in the "Perform Config Diff" node for syntax errors or logic issues | Want to Customize ? Need help setting up or customizing this Environment Config Sync for iOS Xcode Projects workflow? The n8n experts at WeblineIndia can assist you with: Customizing the workflow to fit your specific iOS project structure Integrating with additional tools and services in your CI/CD pipeline Implementing advanced configuration validation and management Setting up multi-environment support and promotion workflows Training your team on iOS configuration management best practices

Create GitHub issues from webhook input and send alerts to Telegram This workflow streamlines bug tracking by using a webhook to collect issue reports, automatically classifying and summarizing them with Gemini AI, then sending critical issues to GitHub and real-time notifications to Telegram. Optional manager approval is built in for low-priority reports. 🧑‍💻 Who’s it for This workflow is ideal for: Engineering teams needing automated issue tracking from multiple systems QA testers or customer support agents who log bugs via custom tools DevOps teams monitoring logs or error reports in real time Teams using GitHub for issue tracking and Telegram (or any messenger) for notifications ⚙️ How it works Webhook Trigger – Listens for incoming POST requests containing bug or task data. AI-Powered Classification – Uses the Gemini model to classify bugs as High or Low severity. Optional Approval – If severity is Low, it waits for a manager’s approval before proceeding. Bug Summary Generation – Passes through a filter and sends the input to Gemini to generate a clean summary. Create GitHub Issue – Submits the summarized issue to your GitHub repository. Telegram Notification – Sends a formatted message to a Telegram group or manager, depending on the path. 🛠️ How to set up Replace the GitHub node with your repo credentials and target repo. Set up the Telegram bot token and chat ID in the Telegram node. Customize the Gemini prompts for your preferred classification and summary logic. Define the conditions for “High” vs “Low” severity based on your data. 📋 Requirements A GitHub account with a personal access token (with repo access) A Telegram bot token and group chat ID Google Gemini API credentials (or your preferred AI model integration) 🔧 How to customize the workflow Swap Telegram with another messaging platform like Slack, Discord, or Microsoft Teams. Adjust classification rules to match your business logic. Change approval flow to notify a different person or add additional logic before sending to GitHub. Extend the webhook input format to support richer data, such as user info or system metadata.