diff --git a/.github/prompts/implement.prompt.md b/.github/prompts/implement.prompt.md index 8f92b2da..93390842 100644 --- a/.github/prompts/implement.prompt.md +++ b/.github/prompts/implement.prompt.md @@ -15,7 +15,7 @@ $ARGUMENTS **Workflow Modes**: This command supports two modes: - **Local (default)**: Work with the current repository (origin). No special configuration needed. -- **Fork**: Contribute to an upstream repository. Reads `.fork-info.json` created by `/specify`. +- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`. **Iteration Support**: This command supports iterative implementation — you can run it multiple times to complete remaining tasks, fix issues, or add refinements. Task completion state is tracked in `tasks.md` with `[X]` markers. @@ -25,11 +25,14 @@ $ARGUMENTS 1. **Set Implementing label immediately** - **Determine target repository**: - - Check if `.fork-info.json` exists in the feature directory. - - If it exists: - - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty). - - Use `upstream_owner/upstream_repo` for all GitHub operations. - - If it doesn't exist, use the current repository (origin). + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. - Get the issue number associated with the current feature branch. - **Add `Implementing` label** to the issue and PR immediately in the target repository. - **Remove `Planning` label** from the issue and PR. @@ -158,7 +161,6 @@ $ARGUMENTS * Remove `Implementing` label. * Ensure PR is not draft. - * Sync `.fork-info.json` with issue + PR numbers. **Fallback commands:** diff --git a/.github/prompts/plan.prompt.md b/.github/prompts/plan.prompt.md index 803155e0..5fda97f5 100644 --- a/.github/prompts/plan.prompt.md +++ b/.github/prompts/plan.prompt.md @@ -12,7 +12,7 @@ $ARGUMENTS **Workflow Modes**: This command supports two modes: - **Local (default)**: Work with the current repository (origin). No special configuration needed. -- **Fork**: Contribute to an upstream repository. Reads `.fork-info.json` created by `/specify`. +- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`. **Iteration Support**: This command detects whether you're creating a new plan or updating an existing one based on the presence of plan.md in the feature directory. @@ -20,11 +20,14 @@ Given the implementation details provided as an argument, do this: 1. **Set Planning label immediately**: - **Determine target repository**: - - Check if `.fork-info.json` exists in the feature directory - - If it exists: - - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty) - - Use `upstream_owner/upstream_repo` for all GitHub operations - - If it doesn't exist, use the current repository (origin) + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. - Get the issue number associated with the current feature branch - **Add 'Planning' label** to the issue immediately in the target repository - **Remove 'Specification' label** from the issue @@ -82,13 +85,14 @@ Given the implementation details provided as an argument, do this: 8. Create or update a Pull Request: - **Determine workflow mode and target repository**: - - Check if `.fork-info.json` exists in the feature directory (same directory as spec.md) - - **If exists** (fork mode): - - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty) - - If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo." - - Use `upstream_owner/upstream_repo` for all GitHub operations - - **If not exists** (local mode - default): - - Use the current repository (origin) for all GitHub operations + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. - **Determine PR operation** (create vs update): - If PR already exists for this branch, UPDATE it - If no PR exists, CREATE a new one @@ -119,18 +123,6 @@ Given the implementation details provided as an argument, do this: * **Version/change level label**: Based on the type of change: `Major`, `Minor`, `Patch`, `Fix`, or `Docs` * **Phase label**: `Planning` (to indicate current phase) - Link the PR to the associated issue - - **After PR creation**: Update `.fork-info.json` (if it exists) with the PR number: - ```json - { - "is_fork": true, - "upstream_owner": "...", - "upstream_repo": "...", - "detected_from": "user_input", - "created_at": "...", - "issue_number": , - "pr_number": - } - ``` **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to create/update the PR and manage labels automatically in the target repository. If not available, provide these fallback commands with the correct repository: ```bash diff --git a/.github/prompts/pr.prompt.md b/.github/prompts/pr.prompt.md new file mode 100644 index 00000000..28cf821d --- /dev/null +++ b/.github/prompts/pr.prompt.md @@ -0,0 +1,170 @@ +--- +description: Create a pull request with a release note style description, appropriate title, and labels based on the change type. +--- + +# PR + +The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty). + +## User input + +$ARGUMENTS + +**Purpose**: Create or update a pull request with a release note style description and title, automatically applying the appropriate labels based on the change type specified. + +## Supported Change Types + +| Type | Icon | Labels | Description | +|------|------|--------|-------------| +| Major | 🌟 | `Major` | Breaking changes that affect compatibility | +| Minor | 🚀 | `Minor` | New features or enhancements | +| Patch | 🩹 | `Patch` | Small fixes or improvements | +| Fix | 🪲 | `Fix`, `Patch` | Bugfixes | +| Docs | 📖 | `Docs` | Documentation changes only | + +## Execution Steps + +1. **Detect repository mode**: + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. + +2. **Determine the change type**: + 1. Parse the user input to identify the change type (Major, Minor, Patch, Fix, or Docs) + 2. If nothing is provided, **analyze ALL changes in the branch** to infer the type: + - Run `git diff origin/main...HEAD --name-only` to get all changed files in the branch + - Read the diff content using `git diff origin/main...HEAD` to understand the nature of changes + - Categorize based on ALL changes combined, not just recent commits: + * **Docs**: ONLY if ALL changes are to documentation files (*.md, docs/, .github/prompts/, etc.) with no code/functionality changes + * **Fix**: If changes specifically fix bugs without adding new features + * **Patch**: Small fixes or improvements that do not add new features + * **Minor**: New features or enhancements that do not break existing functionality + * **Major**: Changes that break backward compatibility (e.g., removing public APIs, changing method signatures) + - **Important**: If the branch contains BOTH code changes AND documentation changes, classify based on the code changes, not the documentation + - **Important**: Check the entire branch diff, not just uncommitted changes or the last commit + +3. **Stage, commit, and push all changes**: + - **ALWAYS run these commands before creating/updating the PR**: + 1. `git add .` - Stage all changes (tracked and untracked files) + 2. Check if there are staged changes with `git diff --cached --quiet` + 3. If there are staged changes, commit with: `git commit -m "Update for PR"` + 4. `git push origin ` - Push to origin remote (even in fork mode) + - This ensures the PR reflects all local changes + - Get the current branch name for the push command + +4. **Retrieve linked issue information** (if available): + - Attempt to find the GitHub issue number associated with the current branch + - If found, retrieve the issue title from the **target repository** (upstream in fork mode, origin otherwise) + - Use the issue title as the PR title (with appropriate icon prefix) + - If no issue is found, ask the user to provide one of the following: + - the number of the issue to link to the PR + - if a new issue should be raised for this PR + - Stop if the user cannot provide either of these. + +5. **Generate PR title**: + - **If issue title retrieved**: Use format ` ` + - Examples: + - `🚀 [Feature]: Add support for custom module templates` + - `🪲 [Fix]: Resolve null reference in parameter validation` + - `📖 [Docs]: Update installation guide with prerequisites` + +6. **Generate release note style description**: + - The PR description will be used automatically as the release note in an automated release + - Use this exact structure (ordered list format): + + **1. Leading Paragraph (Summary)** + - Write a concise paragraph describing **what changes for the user** of the solution + - Focus on user-facing value and impact, not implementation details + - Use present tense and active voice + - Audience: Users of the solution (not developers) + + **2. Issue Links (Unordered List)** + - Add one or more issue links as unordered list items + - Format: `- Fixes #` + - If multiple issues: `- Fixes #`, `- Fixes #` + + **3. Details (Sections with Headers)** + - For each significant change, add a header (e.g., `## Configuration`, `## Breaking Changes`, `## Usage`) + - Under each header, provide: + * Details of what changed + * What the user needs to change or do differently (if anything) + * Examples or code snippets if helpful for understanding + - Keep sections concise and user-focused + - Avoid implementation details unless necessary for user understanding + + **Example Structure:** + ````markdown + The workflow now provides fine-grained control over repository linting behavior through simple configuration options. You can disable the linter entirely or customize which validations run by configuring super-linter environment variables directly in your settings file. + + - Fixes #218 + + ## Configure settings for repository linting + + You can now control the linter behavior via the `Linter` section in your `.settings.yml` file. This allows you to skip linting altogether or customize which validations are performed. + + Added `Linter.Skip` and `Linter.env` settings to control linter behavior. You can now disable the linter entirely or customize which validations run. + + To disable the linter: + ```yaml + Linter: + Skip: true + ``` + + To customize validations: + ```yaml + Linter: + env: + VALIDATE_JSCPD: false + ``` + + ```` + +7. **Create or update the pull request**: + - **Check if PR already exists** for this branch in the **target repository** (upstream in fork mode, origin otherwise) + - **If PR exists**: Update the title, description, and labels + - **If PR does not exist**: Create a new PR from your fork's branch to the target repository's default branch + - In fork mode, the PR will be from `:` to `:` + - Set PR to target the default branch (main/master) of the target repository + - Open as a **draft PR** (or keep as draft if updating) + - **Use GitHub MCP tools** to perform these operations in the **target repository**: + - Create PR (if not exists) - owner/repo should be target repository, use `mcp_github_github_create_pull_request` + - Update PR (if exists) - owner/repo should be target repository, use `mcp_github_github_update_pull_request` + - Add labels to PR - owner/repo should be target repository, use `mcp_github_github_add_labels_to_issue` (PRs are issues in GitHub API) + +8. **Apply labels to the PR**: + - Add the **change type label** based on the type specified (Major, Minor, Patch, Fix, or Docs) + - For Fix type, add both `Fix` and `Patch` labels + - If currently in a feature workflow phase (e.g., Planning, Implementation), also apply that phase label + - Use GitHub MCP to add labels in the **target repository** (upstream in fork mode, origin otherwise) + +9. **Confirm completion**: + - Display the PR URL to the user + - Summarize the PR title, type, and labels applied + - If in fork mode, remind the user that the PR was created in the upstream repository + +## Example usage + +- `/PR` - Create a PR for the current changes +- `/PR Minor` - Create a PR for a new feature +- `/PR Fix` - Create a PR for a bugfix +- `/PR Docs` - Create a PR for documentation changes +- `/PR Major` - Create a PR for breaking changes +- `/PR Patch` - Create a PR for small improvements + +## Notes + +- **This command always stages all changes (`git add .`), commits if needed, and pushes to origin before creating/updating the PR** +- Changes are always pushed to `origin` remote +- In fork mode, PRs and Issue operations are performed on the `upstream` repository +- In origin mode, all operations use the `origin` repository +- The PR is always created as a draft to allow for review before marking as ready +- Labels can be manually adjusted after PR creation if needed +- **The PR description uses a structured format designed for automated release notes**: + 1. Leading paragraph (user-focused summary) + 2. Issue links (unordered list) + 3. Details (sections with headers explaining changes and user actions needed) diff --git a/.github/prompts/specify.prompt.md b/.github/prompts/specify.prompt.md index 813bce62..0f0d7447 100644 --- a/.github/prompts/specify.prompt.md +++ b/.github/prompts/specify.prompt.md @@ -12,7 +12,7 @@ $ARGUMENTS **Workflow Modes**: This command supports two modes: - **Local (default)**: Work with the current repository (origin). No special configuration needed. -- **Fork**: Contribute to an upstream repository. Requires explicit declaration with upstream owner/repo information. +- **Fork**: Contribute to an upstream repository. Automatically detected via `git remote -v`. **Iteration Support**: This command detects whether you're creating a new feature or refining an existing one based on your current branch. @@ -20,30 +20,15 @@ The text the user typed after `/specify` in the triggering message **is** the fe Given that feature description, do this: -1. **Check for fork contribution**: Analyze the user input for mentions of contributing to a fork or upstream repository. Look for phrases like: - - "fork contribution" - - "contributing to upstream" - - "fork of [owner/repo]" - - "upstream repo [owner/repo]" - - Any explicit mention of working on a fork - - If detected, extract the upstream repository information (owner/repo). - - **If fork contribution is detected but information is incomplete**, prompt the user: - - ```text - Fork contribution detected. Please provide the following information: - - Upstream organization/owner name (e.g., "microsoft", "PSModule") - - Upstream repository name (e.g., "vscode", "PSModule") - - Git remote name for upstream (optional, defaults to "upstream") - - Example: "upstream owner: PSModule, upstream repo: Utilities" - ``` - - Wait for user response and re-parse the input before proceeding. Required fields: - - `upstream_owner` (string, non-empty) - - `upstream_repo` (string, non-empty) - - `upstream_remote` (string, optional, defaults to "upstream") +1. **Detect repository mode**: + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. 2. Analyze the feature description and generate a concise, descriptive branch name: - Extract the core concept/action from the description (2-4 words maximum) @@ -62,29 +47,9 @@ Given that feature description, do this: - If you're already on a feature branch (starts with 3 digits like `001-`, `002-`, etc.), you'll stay on that branch to iterate on the existing feature. - This allows you to refine specifications without creating multiple branches for the same feature. -4. **Store fork information (if detected in step 1)**: - - If the user indicated this is a fork contribution, create a `.fork-info.json` file in the feature directory (same location as SPEC_FILE) - - **Validate required fields before creating**: - - `upstream_owner` must be non-empty string - - `upstream_repo` must be non-empty string - - If validation fails, return to step 1 for clarification - - The file should contain: - ```json - { - "is_fork": true, - "upstream_owner": "", - "upstream_repo": "", - "upstream_remote": "", - "detected_from": "user_input", - "created_at": "" - } - ``` - - This file will be used by `/plan` and `/implement` commands to create issues and PRs in the correct repository - - If fork information was detected, inform the user: "Fork contribution detected. Issues and PRs will target `/`" - -5. Load [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) to understand required sections. - -6. **Write or update the specification**: +4. Load [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) to understand required sections. + +5. **Write or update the specification**: - **If IS_EXISTING_BRANCH is false** (new feature on main branch): - Write a new specification to SPEC_FILE using the template structure - Replace placeholders with concrete details derived from the feature description @@ -102,14 +67,10 @@ Given that feature description, do this: - Maintain the template structure and section order - The goal is evolution, not replacement - build upon the existing spec rather than starting over -7. Create or update a GitHub issue for this feature: - - **Determine target repository**: - - Check if `.fork-info.json` exists in the feature directory - - If it exists: - - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty) - - If validation fails, prompt user for correct information (see step 1) - - Use `upstream_owner/upstream_repo` for all GitHub operations - - If it doesn't exist, use the current repository (origin) +6. Create or update a GitHub issue for this feature: + - **Use target repository determined in step 1**: + - If fork mode: Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - If origin mode: Use `origin` owner/repo for all operations (both git push and GitHub operations) - **Generate the issue title** in format ` [Type]: ` where: - Icon: 📖 (Docs), 🪲 (Fix), ⚠️ (Security fix), 🩹 (Patch), 🚀 (Feature/Minor), 🌟 (Breaking change/Major) - Type: Docs, Fix, Patch, Feature, or Breaking change @@ -142,8 +103,8 @@ Given that feature description, do this: gh issue edit --body-file ``` -8. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`." +7. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`." -9. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase. +8. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase. Note: The script handles branch creation/reuse and initializes the spec file before writing. diff --git a/.github/prompts/tasks.prompt.md b/.github/prompts/tasks.prompt.md index 8ed82218..3cfc71d0 100644 --- a/.github/prompts/tasks.prompt.md +++ b/.github/prompts/tasks.prompt.md @@ -12,7 +12,7 @@ $ARGUMENTS **Workflow Modes**: This command supports two modes: - **Local (default)**: Work with the current repository (origin). No special configuration needed. -- **Fork**: Contribute to an upstream repository. Reads `.fork-info.json` created by `/specify`. +- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`. **Iteration Support**: This command detects whether you're creating new tasks or updating existing ones based on the presence of tasks.md in the feature directory. @@ -83,13 +83,14 @@ $ARGUMENTS 8. Update the Pull Request description: - **Determine workflow mode and target repository**: - - Check if `.fork-info.json` exists in the feature directory (same location as plan.md) - - **If exists** (fork mode): - - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty) - - If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo." - - Use `upstream_owner/upstream_repo` for all GitHub operations - - **If not exists** (local mode - default): - - Use the current repository (origin) for all GitHub operations + - Run `git remote -v` to check configured remotes. + - **If `upstream` remote exists**: Fork mode + - Use `upstream` owner/repo for all GitHub operations (PRs, Issues, labels) + - Use `origin` for all git operations (push, fetch) + - **If only `origin` remote exists**: Origin mode + - Use `origin` owner/repo for all operations (both git push and GitHub operations) + - Parse the URLs to extract owner and repo name: `https://github.com//.git`. + - If in doubt, ask the user to clarify which repository to target. - Append or update the tasks.md content in the existing PR description - Format tasks with checkboxes for each task phase: * Setup: `- [ ] T001: Task description` diff --git a/.github/workflows/Get-Settings.yml b/.github/workflows/Get-Settings.yml index 2f502542..2b2ed220 100644 --- a/.github/workflows/Get-Settings.yml +++ b/.github/workflows/Get-Settings.yml @@ -230,6 +230,10 @@ jobs: } } + Linter = [pscustomobject]@{ + Skip = $settings.Linter.Skip ?? $false + env = $settings.Linter.env ?? @{} + } } LogGroup "Final settings" { switch -Regex ($settingsFile.Extension) { diff --git a/.github/workflows/workflow.yml b/.github/workflows/workflow.yml index faf24e77..c10e9a73 100644 --- a/.github/workflows/workflow.yml +++ b/.github/workflows/workflow.yml @@ -70,6 +70,10 @@ permissions: pages: write # to deploy to Pages id-token: write # to verify the deployment originates from an appropriate source +defaults: + run: + shell: pwsh + jobs: # Runs on: # - ✅ Open/Updated PR - Always runs to load configuration @@ -95,7 +99,7 @@ jobs: Lint-Repository: name: Lint code base runs-on: ubuntu-latest - if: github.event_name == 'pull_request' && github.event.pull_request.merged != true && github.event.action != 'closed' + if: github.event_name == 'pull_request' && github.event.pull_request.merged != true && github.event.action != 'closed' && fromJson(needs.Get-Settings.outputs.Settings).Linter.Skip != true needs: - Get-Settings steps: @@ -105,17 +109,32 @@ jobs: persist-credentials: false fetch-depth: 0 + - name: Load dynamic envs + env: + SETTINGS: ${{ needs.Get-Settings.outputs.Settings }} + run: | + Write-Host "Loading settings for super-linter:" + $settings = $env:SETTINGS | ConvertFrom-Json -AsHashtable + $linter = $settings.Linter + $env = $linter.env + + foreach ($key in $env.Keys) { + $value = $env[$key] + + if ($value -is [bool]) { + $value = $value.ToString().ToLower() + } + + Write-Host "$key = $value" + + # Persist for following steps in this job + "$key=$value" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append + } + - name: Lint code base uses: super-linter/super-linter@7bba2eeb89d01dc9bfd93c497477a57e72c83240 # v8.2.0 env: GITHUB_TOKEN: ${{ github.token }} - VALIDATE_BIOME_FORMAT: false - VALIDATE_BIOME_LINT: false - VALIDATE_GITHUB_ACTIONS_ZIZMOR: false - VALIDATE_JSCPD: false - VALIDATE_JSON_PRETTIER: false - VALIDATE_MARKDOWN_PRETTIER: false - VALIDATE_YAML_PRETTIER: false # Runs on: # - ✅ Open/Updated PR - Builds module for testing diff --git a/README.md b/README.md index f912c330..c273f502 100644 --- a/README.md +++ b/README.md @@ -260,6 +260,8 @@ The following settings are available in the settings file: | `Publish.Module.MinorLabels` | `String` | Labels indicating a minor version bump | `'minor, feature'` | | `Publish.Module.PatchLabels` | `String` | Labels indicating a patch version bump | `'patch, fix'` | | `Publish.Module.IgnoreLabels` | `String` | Labels indicating no release | `'NoRelease'` | +| `Linter.Skip` | `Boolean` | Skip repository linting | `false` | +| `Linter.env` | `Object` | Environment variables for super-linter configuration | `{}` |
`PSModule.yml` with all defaults @@ -328,6 +330,10 @@ Publish: PatchLabels: 'patch, fix' IgnoreLabels: 'NoRelease' +Linter: + Skip: false + env: {} + ```
@@ -365,6 +371,59 @@ Build: Skip: true ``` +### Example 3 - Configuring the Repository Linter + +The workflow uses [super-linter](https://github.com/super-linter/super-linter) to lint your repository code. +The linter runs on pull requests and provides status updates directly in the PR. + +#### Disabling the Linter + +You can skip repository linting entirely: + +```yaml +Linter: + Skip: true +``` + +#### Configuring Linter Validation Rules + +The workflow supports all environment variables that super-linter provides. You can configure these through the `Linter.env` object: + +```yaml +Linter: + env: + # Disable specific validations + VALIDATE_BIOME_FORMAT: false + VALIDATE_BIOME_LINT: false + VALIDATE_GITHUB_ACTIONS_ZIZMOR: false + VALIDATE_JSCPD: false + VALIDATE_JSON_PRETTIER: false + VALIDATE_MARKDOWN_PRETTIER: false + VALIDATE_YAML_PRETTIER: false + + # Or enable only specific validations + VALIDATE_YAML: true + VALIDATE_JSON: true + VALIDATE_MARKDOWN: true +``` + +#### Additional Configuration + +Any super-linter environment variable can be set through the `Linter.env` object: + +```yaml +Linter: + env: + LOG_LEVEL: DEBUG + FILTER_REGEX_EXCLUDE: '.*test.*' + VALIDATE_ALL_CODEBASE: false +``` + +**Note:** The `GITHUB_TOKEN` is automatically provided by the workflow to enable status updates in pull requests. + +For a complete list of available environment variables and configuration options, see the +[super-linter environment variables documentation](https://github.com/super-linter/super-linter#environment-variables). + ## Specifications and practices The process is compatible with: diff --git a/tests/srcTestRepo/.github/PSModule.yml b/tests/srcTestRepo/.github/PSModule.yml new file mode 100644 index 00000000..2607ddb5 --- /dev/null +++ b/tests/srcTestRepo/.github/PSModule.yml @@ -0,0 +1,2 @@ +Linter: + Skip: true diff --git a/tests/srcWithManifestTestRepo/.github/PSModule.json b/tests/srcWithManifestTestRepo/.github/PSModule.json deleted file mode 100644 index b175eeb5..00000000 --- a/tests/srcWithManifestTestRepo/.github/PSModule.json +++ /dev/null @@ -1,22 +0,0 @@ -{ - "Name": "PSModuleTest", - "Test": { - "SourceCode": { - "Skip": true - }, - "PSModule": { - "Linux": { - "Skip": true - } - }, - "Module": { - "Skip": false - }, - "CodeCoverage": { - "PercentTarget": 1 - } - }, - "Publish": { - "AutoCleanup": false - } -} diff --git a/tests/srcWithManifestTestRepo/.github/PSModule.psd1 b/tests/srcWithManifestTestRepo/.github/PSModule.psd1 deleted file mode 100644 index e680e8fd..00000000 --- a/tests/srcWithManifestTestRepo/.github/PSModule.psd1 +++ /dev/null @@ -1,22 +0,0 @@ -@{ - Name = 'PSModuleTest' - Test = @{ - SourceCode = @{ - Skip = $true - } - PSModule = @{ - Linux = @{ - Skip = $true - } - } - Module = @{ - Skip = $false - } - CodeCoverage = @{ - PercentTarget = 1 - } - } - Publish = @{ - AutoCleanup = $false - } -} diff --git a/tests/srcWithManifestTestRepo/.github/PSModule.yml b/tests/srcWithManifestTestRepo/.github/PSModule.yml index d285c1ed..ceaf2ff0 100644 --- a/tests/srcWithManifestTestRepo/.github/PSModule.yml +++ b/tests/srcWithManifestTestRepo/.github/PSModule.yml @@ -11,3 +11,12 @@ Test: PercentTarget: 1 Publish: AutoCleanup: false +Linter: + env: + VALIDATE_BIOME_FORMAT: false + VALIDATE_BIOME_LINT: false + VALIDATE_GITHUB_ACTIONS_ZIZMOR: false + VALIDATE_JSCPD: false + VALIDATE_JSON_PRETTIER: false + VALIDATE_MARKDOWN_PRETTIER: false + VALIDATE_YAML_PRETTIER: false