Evergreen Apps Repository

Welcome to the Evergreen Apps repo! This is repo hosts application functions and manifests for the Evergreen module.

What is This Repo?

This repository hosts:

• Application Functions: The logic that powers Evergreen's supported application features.
• Manifests: Configuration files that describe how apps detection works.

Check out Evergreen Documentation for detailed guides.

How to Use

If you want to contribute to this project with fixes or new applications, set up your local environment as follows:

1. Install the Evergreen module, or clone the evergreen-module repository.
2. Clone this repository.
3. Configure the Evergreen environment for local development by creating the EVERGREEN_APPS_PATH environment variable, pointing to the location of the local repository: Set a custom cache location. For example:

$env:EVERGREEN_APPS_PATH="C:\projects\evergreen-apps"

or

$env:EVERGREEN_APPS_PATH="/Users/aaron/projects/_EUCPilots/evergreen-apps"

4. Import the Evergreen module, for example:

Import-Module -Name Evergreen -Force

or

Import-Module -Name "/Users/aaron/projects/_EUCPilots/evergreen-module/Evergreen" -Force

5. Implement your changes in a new branch and create a pull request.

Delegate an Issue to GitHub Copilot

The Evergreen App Maintainer agent handles both existing application bugs and new application requests. It reads AGENTS.md and RULES.md, investigates the issue, updates the app function and manifest as needed, and validates the local definitions. New applications must have a viable public machine-readable source; the agent reports a blocker rather than inventing one.

One-time setup

1. Merge the agent configuration and Copilot setup workflow into the default branch so GitHub can discover them.
2. Ensure your account has access to Copilot cloud agent, the organization's Copilot policy permits it, and it is enabled for this repository. The person assigning an issue needs write access. Cloud runs consume Copilot usage and GitHub Actions resources according to your plan.
3. Run Copilot setup steps manually in Actions to verify that the runner can install Evergreen, PSScriptAnalyzer, and Pester from PSGallery. Setup uses Ubuntu's PowerShell 7 and read-only repository permissions; GitHub supplies the agent's separate task permissions. No dispatch token or additional repository secret is required.
4. If a required vendor API is blocked by the Copilot firewall, review the domain and configure the repository's Copilot network allowlist as needed. Do not disable the firewall or give the agent credentials for vendor sites.

Start a run

1. Create or complete the app bug or new-application issue. Include the application name, vendor/source links, and reproduction details or the information requested by the new-app issue template.
2. Open Assignees, select Copilot, and choose Evergreen App Maintainer in the agent dropdown. Add any task-specific context in the optional prompt before confirming assignment.
3. Copilot works unattended on its own branch and opens a pull request. Review its diff, source evidence, validation results, and any blockers before merging. The agent is instructed not to merge or push to the default branch.
4. Send follow-up requests with @copilot on the pull request. Copilot receives the issue's existing comments at assignment time; later issue comments are not automatically included in that task.

This uses GitHub's native issue assignment, not a custom issue-comment trigger. Mentioning the agent name or @copilot in an issue comment alone does not start this workflow. VS Code's Autopilot mode is a local chat setting, not a switch for cloud runs. GitHub may still require maintainer approval before running Actions on an agent pull request. Missing source information or blocked validation is reported for review rather than silently treated as success.

For Windows-specific behavior, run the existing Test Evergreen app workflow against the agent's branch before merging.

See GitHub's documentation for assigning issues and selecting custom agents and configuring the agent environment.

Testing an Application on Windows

Run the Test Evergreen app workflow manually from the repository's Actions tab. Select a branch and enter an Evergreen application name, such as MicrosoftPowerAutomateDesktop.

The workflow installs Evergreen from PSGallery on windows-latest and uses the selected branch's application functions and manifests. Separate matrix jobs test PowerShell 7 (pwsh) and Windows PowerShell 5.1 (powershell), and a failure in one job does not cancel the other. The test step logs runner, PowerShell, and module details, along with verbose application output. Results or full error details and the script stack trace are also written to the run summary. Errors and empty application results fail the job.

Automatic Similar-Issue Suggestions

The Similar issues workflow checks opened, edited, and reopened issues against earlier open and closed reports. It detects application names using the manifests, ranks reports for the same application by shared symptom words, and prioritizes reports labelled information or vendor issue. When no application is detected, it requires at least three shared significant words and 50% overlap with the shorter description. Form boilerplate and verbose logs are excluded from symptom scoring.

When related reports or an application-specific section in the known-issues documentation are found, the workflow posts up to five issue links and the relevant documentation link, and creates/applies the similar issues label. Suggestions are not duplicate determinations: it never closes issues or copies classification labels. Edits update the same bot comment; if matches disappear, the workflow removes its comment and label.

Merge the workflow and its script into the default branch to enable issue events. No additional secrets or external AI service are required; the workflow uses GITHUB_TOKEN with read access to contents and write access to issues. It reads only trusted default-branch code, treating issue text as data. API and documentation failures fail the run rather than posting partial results.

To preview an existing report, run Similar issues manually with its issue number (for example, 241) and leave dry_run enabled. Review the Actions run summary, then rerun with dry_run disabled to post suggestions. The workflow tests also run on pull requests affecting its files. Run them locally with:

node --test tests/similar-issues.test.cjs