{"meta":{"title":"Workspaces CodeQL","intro":"CodeQL Рабочие пространства позволяют разрабатывать и поддерживать несколько связанных CodeQL пакетов вместе, разрешая зависимости между ними напрямую из источника.","product":"Безопасность и качество кода","breadcrumbs":[{"href":"/ru/enterprise-cloud@latest/code-security","title":"Безопасность и качество кода"},{"href":"/ru/enterprise-cloud@latest/code-security/concepts","title":"Concepts"},{"href":"/ru/enterprise-cloud@latest/code-security/concepts/code-scanning","title":"Проверка кода"},{"href":"/ru/enterprise-cloud@latest/code-security/concepts/code-scanning/codeql","title":"CodeQL"},{"href":"/ru/enterprise-cloud@latest/code-security/concepts/code-scanning/codeql/codeql-workspaces","title":"Workspaces CodeQL"}],"documentType":"article"},"body":"# Workspaces CodeQL\n\nCodeQL Рабочие пространства позволяют разрабатывать и поддерживать несколько связанных CodeQL пакетов вместе, разрешая зависимости между ними напрямую из источника.\n\n## О CodeQL рабочих местах\n\nCodeQL Рабочее пространство обычно используется для разработки набора библиотечных и запросных пакетов, которые зависят друг от друга. Когда вы используете CodeQL рабочее пространство, все CodeQL паки в этом пространстве доступны как *исходные зависимости* друг для друга при запуске CodeQL команды, разрешающей запросы. Это облегчает разработку, поддержку и публикацию нескольких связанных CodeQL пакетов. Для получения дополнительной информации о CodeQL паках смотрите [Настройка анализа с помощью пакетов CodeQL](/ru/enterprise-cloud@latest/code-security/codeql-cli/getting-started-with-the-codeql-cli/customizing-analysis-with-codeql-packs).\n\nРабочие пространства обычно хранятся в одном репозитории Git, чтобы связанные паки можно было разрабатывать и публиковать вместе.\n\n## Зависимости источника\n\nВ рабочем пространстве все пакеты, CodeQL включённые в рабочее пространство, рассматриваются как **зависимости исходного** кода друг от друга. Это означает, что они разрешаются напрямую из локальной файловой системы, а не из кэша CodeQL пакетов.\n\nПотому что рабочие пакеты разрешаются из источника:\n\n* Локальные изменения в одном наборе сразу видны другим наборам в рабочем пространстве.\n* Зависимости, найденные в рабочем пространстве, переопределяют версии в кэше пакетов.\n* Ограничения по версиям в `qlpack.yml` файлах игнорируются в зависимости от рабочего пространства, так как версия определяется содержимым рабочего пространства.\n\nЭто поведение особенно полезно при одновременной разработке нескольких связанных пакетов. Рассмотрим пример.\n\n* Зависимость пока не опубликована и существует только локально.\n* Вы вносите скоординированные изменения в несколько пакетов и хотите, чтобы они разрешались друг против друга во время тестирования.\n\nВне рабочего пространства зависимости разрешаются из кэша пакета и должны соответствовать ограничениям версии, определённым в `qlpack.yml`. Внутри рабочего пространства резолюция отдаёт приоритет локальному исходному контенту.\n\n## CodeQL Рабочие пространства и разрешение запросов\n\nМодель зависимости рабочего пространства влияет на то, как пакеты устанавливаются и публикуются.\n\n* Во время установки зависимости, найденные в рабочем пространстве, не загружаются в кэш пакета и не записываются в `codeql-pack.lock.yml` файл.\n* Во время публикации зависимости, предоставляемые рабочим пространством, объединяются с использованием локального исходного контента, а не версий из кэша пакетов.\n\nНапример, запуск `codeql pack install` в каталоге pack внутри рабочего пространства использует любые зависимости, найденные в этом пространстве, вместо того чтобы загружать их в кэш пакетов или записывать в `codeql-pack.lock.yml` файл. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/creating-and-working-with-codeql-packs#adding-and-installing-dependencies).\n\n### Example\n\nРабочее CodeQL пространство определяется YAML-файлом с именем `codeql-workspace.yml`. Рассмотрим следующий файл `codeql-workspace.yml`:\n\n```yaml\nprovide:\n  - \"**/qlpack.yml\"\n```\n\nИ следующий CodeQL файл пакета `qlpack.yml` библиотеки в рабочем пространстве:\n\n```yaml\nname: my-company/my-library\nlibrary: true\nversion: 1.0.0\n```\n\nИ следующий CodeQL файл пакета `qlpack.yml` запросов в рабочем пространстве:\n\n```yaml\nname: my-company/my-queries\nversion: 1.0.0\ndependencies:\n  my-company/my-library: \"*\"\n  codeql/cpp-all: ~0.2.0\n```\n\nОбратите внимание, что `dependencies` блок для CodeQL пакета запросов, `my-company/my-queries`, указывает `\"*\"` как версию библиотечного пака. Так как пакет библиотеки уже определен как зависимость источника `codeql-workspace.yml`, содержимое пакета библиотеки всегда разрешается из рабочей области. Любое ограничение версии, указанное вами, будет игнорироваться в этом случае. Использование `\"*\"` для исходных зависимостей явно показывает, что версия унаследована из рабочего пространства.\n\nПри выполнении `codeql pack install` из каталога пакета запросов соответствующая версия `codeql/cpp-all` загружается в локальный кэш пакетов. Кроме того, `codeql-pack.lock.yml` создается файл, содержащий разрешенную версию `codeql/cpp-all`. Файл блокировки не будет содержать запись `my-company/my-library` , так как она разрешается из исходных зависимостей. Файл `codeql-pack.lock.yml` будет выглядеть примерно так:\n\n```yaml\ndependencies:\n  codeql/cpp-all:\n    version: 0.2.2\n```\n\nКогда вы запускаете `codeql pack publish` из каталога пакета запросов, `codeql/cpp-all` зависимости из кэша пакета и `my-company/my-library` из рабочего пространства объединяются `my-company/my-queries` и публикуются в реестре GitHub контейнера.\n\n## Пример `codeql-workspace.yml` файла\n\nРабочее CodeQL пространство определяется YAML-файлом с именем `codeql-workspace.yml`. Этот файл содержит `provide` блок и при необходимости `ignore` и `registries` блоки.\n\n* Блок содержит список шаблонов `provide` glob, которые определяют CodeQL пакеты, доступные в рабочем пространстве.\n\n* Блок `ignore` содержит список шаблонов глоба, определяющих CodeQL пакеты, недоступные в рабочем пространстве.\n\n* Блок `registries` содержит список URL GHES и шаблонов упаковок, которые определяют, какой реестр контейнеров используется для публикации CodeQL пакетов. См [. раздел AUTOTITLE](/ru/enterprise-cloud@latest/code-security/codeql-cli/using-the-advanced-functionality-of-the-codeql-cli/publishing-and-using-codeql-packs#working-with-codeql-packs-on-ghes).\n\nКаждая запись в `provide` разделе `ignore` должна сопоставляться с расположением `qlpack.yml` файла. Все шаблоны glob определяются относительно каталога, содержащего файл рабочей области. Список шаблонов, принятых в этом файле, см. в разделе [@actions/glob](https://github.com/actions/toolkit/tree/main/packages/glob#patterns).\n\nНапример, следующий `codeql-workspace.yml` файл определяет рабочее пространство, содержащее все CodeQL пакеты, рекурсивно найденные в `codeql-packs` каталоге, за исключением пакетов в каталоге `experimental` . Блок `registries` указывает, что `codeql/\\*` пакеты должны загружаться из `https://ghcr.io/v2/`, что является GitHubстандартным реестром контейнеров для . Все остальные пакеты следует скачать и опубликовать в реестре `GHE_HOSTNAME`.\n\n```yaml\nprovide:\n  - \"*/codeql-packs/**/qlpack.yml\"\nignore:\n  - \"*/codeql-packs/**/experimental/**/qlpack.yml\"\n\nregistries:\n - packages: 'codeql/*'\n   url: https://ghcr.io/v2/\n\n - packages: '*'\n   url: https://containers.GHE_HOSTNAME/v2/\n```\n\nВы можете перечислить пакеты, включённые в рабочее пространство, запустив `codeql pack ls` их в каталоге workspace.\n\n## Использование `${workspace}` в качестве диапазона версий в файлах `qlpack.yml`\n\nCodeQL Пакеты в рабочем пространстве могут использовать специальные `${workspace}`заглушки диапазона , `~${workspace}`и `^${workspace}` версии. Эти заполнители указывают, что этот пакет зависит от версии указанного пакета, который в настоящее время находится в рабочей области. Этот заполнитель обычно используется для зависимостей внутри пакетов библиотек, чтобы гарантировать, что при публикации зависимости в файле `qlpack.yml` отражают состояние рабочей области при их публикации.\n\n### Example\n\nРассмотрим следующие два пакета библиотеки в одной рабочей области:\n\n```yaml\nname: my-company/my-library\nlibrary: true\nversion: 1.2.3\ndependencies:\n  my-company/my-library2: ${workspace}\n```\n\n```yaml\nname: my-company/my-library2\nlibrary: true\nversion: 4.5.6\n```\n\nПри `my-company/my-library` публикации в реестре GitHub контейнера версия `my-company/my-library2` зависимости в опубликованном `qlpack.yml` файле будет записана как `4.5.6`.\n\nАналогичным образом, если зависимость находится `my-company/my-library2: ^${workspace}` в исходном пакете, а затем будет опубликован пакет, версия `my-company/my-library2` зависимости в опубликованном `qlpack.yml` файле будет записана как `^4.5.6`, указывающая, что версии `>= 4.5.6` и `< 5.0.0` все совместимы с этим пакетом библиотеки.\n\nЕсли зависимость находится `my-company/my-library2: ~${workspace}` в исходном пакете, а затем будет опубликован пакет, версия `my-company/my-library2` зависимостей в опубликованном `qlpack.yml` файле будет записана как `~4.5.6`, указывающая, что версии `>= 4.5.6` и `< 4.6.0` все совместимы с этим пакетом библиотеки."}