{"meta":{"title":"Создание и тестирование для PowerShell","intro":"Узнайте, как создать рабочий процесс непрерывной интеграции (CI) для создания и тестирования проекта PowerShell.","product":"GitHub Actions","breadcrumbs":[{"href":"/ru/actions","title":"GitHub Actions"},{"href":"/ru/actions/tutorials","title":"Учебники"},{"href":"/ru/actions/tutorials/build-and-test-code","title":"Сборка и тестирование кода"},{"href":"/ru/actions/tutorials/build-and-test-code/powershell","title":"PowerShell"}],"documentType":"article"},"body":"# Создание и тестирование для PowerShell\n\nУзнайте, как создать рабочий процесс непрерывной интеграции (CI) для создания и тестирования проекта PowerShell.\n\n## Введение\n\nВ этом руководстве описано использование PowerShell для CI. В нём описывается, как использовать Pester, устанавливать зависимости, тестировать модуль и публиковать в коллекция PowerShell.\n\nGitHub-размещенные средства запуска имеют кэш средств с предварительно установленным программным обеспечением, которое включает PowerShell и Pester.\n\nПолный список актуального программного обеспечения и предварительно установленных версий PowerShell и Pester см. в разделе [Средства выполнения тестов, размещенные в GitHub](/ru/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images).\n\n## Необходимые компоненты\n\nВы должны быть знакомы с YAML и синтаксисом для GitHub Actions. Дополнительные сведения см. в разделе [Написание рабочих процессов](/ru/actions/how-tos/write-workflows).\n\nРекомендуется иметь базовое представление о PowerShell и Pester. Дополнительные сведения см. в разделе:\n\n* [Начало работы с PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)\n* [Pester](https://pester.dev)\n\n## Добавление рабочего процесса для Pester\n\nЧтобы автоматизировать тестирование с помощью PowerShell и Pester, можно добавить рабочий процесс, который запускается при каждой отправке изменения в репозиторий. В следующем примере `Test-Path` используется для проверки наличия файла `resultsfile.log`.\n\nЭтот пример файла рабочего процесса необходимо добавить в каталог `.github/workflows/` репозитория:\n\n```yaml\nname: Test PowerShell on Ubuntu\non: push\n\njobs:\n  pester-test:\n    name: Pester test\n    runs-on: ubuntu-latest\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n      - name: Perform a Pester test from the command-line\n        shell: pwsh\n        run: Test-Path resultsfile.log | Should -Be $true\n      - name: Perform a Pester test from the Tests.ps1 file\n        shell: pwsh\n        run: |\n          Invoke-Pester Unit.Tests.ps1 -Passthru\n```\n\n* `shell: pwsh` — настраивает задание для использования PowerShell при выполнении команд `run`.\n\n* `run: Test-Path resultsfile.log` — проверяет, присутствует ли файл `resultsfile.log` в корневом каталоге репозитория.\n\n* `Should -Be $true` — использует Pester для определения ожидаемого результата. Если результат непредвиден, он GitHub Actions помечает это как неудачный тест. Например:\n\n  ![Снимок экрана: сбой запуска рабочего процесса для теста Pester. Тестовые отчеты \"Ожидаемые $true, но получили $false\" и \"Ошибка: обработка завершена с кодом выхода 1\".](/assets/images/help/repository/actions-failed-pester-test-updated.png)\n\n* `Invoke-Pester Unit.Tests.ps1 -Passthru` — использует Pester для выполнения тестов, определенных в файле `Unit.Tests.ps1`. Например, чтобы выполнить тест, аналогичны описанному выше, `Unit.Tests.ps1` будет содержать следующее:\n\n  ```powershell\n  Describe \"Check results file is present\" {\n      It \"Check results file is present\" {\n          Test-Path resultsfile.log | Should -Be $true\n      }\n  }\n  ```\n\n## Расположения модулей PowerShell\n\nВ таблице ниже описаны расположения для различных модулей PowerShell в каждом GitHubразмещенном средстве выполнения.\n\n<div class=\"ghd-tool rowheaders\">\n\n|                                          | Ubuntu                                           | macOS                                             | Windows                                               |\n| ---------------------------------------- | ------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------- |\n| **Системные модули PowerShell**          | `/opt/microsoft/powershell/7/Modules/*`          | `/usr/local/microsoft/powershell/7/Modules/*`     | `C:\\program files\\powershell\\7\\Modules\\*`             |\n| **Модули надстроек PowerShell**          | `/usr/local/share/powershell/Modules/*`          | `/usr/local/share/powershell/Modules/*`           | `C:\\Modules\\*`                                        |\n| **Устанавливаемые пользователем модули** | `/home/runner/.local/share/powershell/Modules/*` | `/Users/runner/.local/share/powershell/Modules/*` | `C:\\Users\\runneradmin\\Documents\\PowerShell\\Modules\\*` |\n\n</div>\n\n> \\[!NOTE]\n> На Ubuntu Azure PowerShell модули хранятся в `/usr/share/` вместо стандартного расположения дополнительных модулей PowerShell (то есть `/usr/local/share/powershell/Modules/`).\n\n## Установка зависимостей\n\nGitHub-размещенные средства выполнения имеют PowerShell 7 и Pester. Вы можете использовать `Install-Module` для установки дополнительных зависимостей из коллекция PowerShell перед сборкой и тестированием кода.\n\n> \\[!NOTE]\n> Предварительно установленные пакеты (например, Pester), используемые GitHubразмещенными средствами выполнения, регулярно обновляются и могут вносить значительные изменения. Поэтому рекомендуется всегда указывать необходимые версии пакетов, используя `Install-Module` с `-MaximumVersion`.\n\nМожно также кэшировать зависимости, чтобы ускорить рабочий процесс. Дополнительные сведения см. в разделе [Справочник по кэшированию зависимостей](/ru/actions/reference/workflows-and-actions/dependency-caching).\n\nНапример, следующее задание устанавливает модули `SqlServer` и `PSScriptAnalyzer`:\n\n```yaml\njobs:\n  install-dependencies:\n    name: Install dependencies\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Install from PSGallery\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module SqlServer, PSScriptAnalyzer\n```\n\n> \\[!NOTE]\n> По умолчанию репозитории не доверяются PowerShell. При установке модулей с коллекция PowerShell необходимо явно установить политику установки `PSGallery` на `Trusted`.\n\n### Кэширование зависимостей\n\nЗависимости PowerShell можно кэшировать с помощью уникального ключа, что позволяет восстановить зависимости для будущих рабочих процессов посредством действия [`cache`](https://github.com/marketplace/actions/cache). Дополнительные сведения см. в разделе [Справочник по кэшированию зависимостей](/ru/actions/reference/workflows-and-actions/dependency-caching).\n\nPowerShell кэширует свои зависимости в разных расположениях в зависимости от операционной системы средства выполнения. Например, местоположение `path`, используемое в следующем примере Ubuntu, будет отличаться для операционной системы Windows.\n\n```yaml\nsteps:\n  - uses: actions/checkout@v6\n  - name: Setup PowerShell module cache\n    id: cacher\n    uses: actions/cache@v4\n    with:\n      path: \"~/.local/share/powershell/Modules\"\n      key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer\n  - name: Install required PowerShell modules\n    if: steps.cacher.outputs.cache-hit != 'true'\n    shell: pwsh\n    run: |\n      Set-PSRepository PSGallery -InstallationPolicy Trusted\n      Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop\n```\n\n## Тестирование кода\n\nВы можете использовать те же команды, которые используются для создания и тестирования кода в локальной среде.\n\n### Использование PSScriptAnalyzer для анализа кода\n\nВ следующем примере выполняется установка `PSScriptAnalyzer` и его использование для анализа кода всех файлов `ps1` в репозитории. Для получения дополнительной информации см. [PSScriptAnalyzer на GitHub](https://github.com/PowerShell/PSScriptAnalyzer).\n\n```yaml\n  lint-with-PSScriptAnalyzer:\n    name: Install and run PSScriptAnalyzer\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Install PSScriptAnalyzer module\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module PSScriptAnalyzer -ErrorAction Stop\n      - name: Lint with PSScriptAnalyzer\n        shell: pwsh\n        run: |\n          Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues\n          $errors   = $issues.Where({$_.Severity -eq 'Error'})\n          $warnings = $issues.Where({$_.Severity -eq 'Warning'})\n          if ($errors) {\n              Write-Error \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\" -ErrorAction Stop\n          } else {\n              Write-Output \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\"\n          }\n```\n\n## Упаковка данных рабочего процесса в виде артефактов\n\nВы можете отправить артефакты для просмотра после завершения рабочего процесса. Например, может потребоваться сохранить файлы журналов, основные дампы, результаты теста или снимки экрана. Дополнительные сведения см. в разделе [Хранение и предоставление общего доступа к данным с артефактами рабочего процесса](/ru/actions/tutorials/store-and-share-data).\n\nВ следующем примере показано, как использовать действие `upload-artifact` для архивации результатов теста, полученных из `Invoke-Pester`. Дополнительные сведения см. в описании [действия `upload-artifact`](https://github.com/actions/upload-artifact).\n\n```yaml\nname: Upload artifact from Ubuntu\n\non: [push]\n\njobs:\n  upload-pester-results:\n    name: Run Pester and upload results\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Test with Pester\n        shell: pwsh\n        run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml\n      - name: Upload test results\n        uses: actions/upload-artifact@v4\n        with:\n          name: ubuntu-Unit-Tests\n          path: Unit.Tests.xml\n    if: ${{ always() }}\n```\n\nФункция `always()` настраивает задание для продолжения обработки даже при наличии сбоев тестов. Дополнительные сведения см. в разделе [Оценка выражений в рабочих процессах и действиях](/ru/actions/reference/workflows-and-actions/expressions#always).\n\n## Публикация для коллекция PowerShell\n\nВы можете настроить рабочий процесс так, чтобы публиковать модуль PowerShell в коллекция PowerShell после прохождения тестов CI. Вы можете использовать секреты для хранения любых маркеров или учетных данных, необходимых для публикации пакета. Дополнительные сведения см. в разделе [Использование секретов в GitHub Actions](/ru/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets).\n\nСледующий пример создаёт пакет и использует `Publish-Module` для публикации в коллекция PowerShell:\n\n```yaml\nname: Publish PowerShell Module\n\non:\n  release:\n    types: [created]\n\njobs:\n  publish-to-gallery:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\n      - name: Build and publish\n        env:\n          NUGET_KEY: ${{ secrets.NUGET_KEY }}\n        shell: pwsh\n        run: |\n          ./build.ps1 -Path /tmp/samplemodule\n          Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose\n```"}