bicep-code-best-practices — правило для GitHub Copilot: что делает
Правило задаёт рекомендации для Bicep-файлов: от имён параметров до ссылок на ресурсы и работы с секретами. Помогает Copilot придерживаться единого стиля при написании инфраструктурного кода.
.github/instructions/bicep-code-best-practices.instructions.mdЧто делает bicep-code-best-practices
Правило применяется к файлам **/*.bicep. Оно просит объявлять параметры в начале файла и снабжать их описаниями, выбирать стабильные версии API и использовать нижний camelCase для имён. Для переменных рекомендует выносить сложные выражения из свойств ресурсов, а ссылки между ресурсами строить по символическим именам.
Для имён ресурсов правило предлагает применять uniqueString() с префиксом, а дочерние ресурсы описывать через parent или вложенность. Зависимости стоит задавать символическими ссылками, не явным dependsOn; секреты и ключи нельзя помещать в outputs. Это важно учесть: правило также просит задавать безопасные для тестирования значения по умолчанию, включая недорогие тарифы.
Какие задачи решает
- Задать единый стиль имён параметров и ресурсов в Bicep
- Описать параметры и ограничения длины имён
- Заменить явные зависимости ссылками на символические имена
- Сформировать имена ресурсов через
uniqueString()с префиксом - Не допустить попадания секретов в outputs
Примеры запросов агенту
- Создай Bicep-шаблон и соблюдай правило именования параметров и ресурсов.
- Проверь этот файл
.bicep: вынеси сложные выражения в переменные и используй символические ссылки на ресурсы. - Добавь параметры с описаниями и безопасными значениями по умолчанию для тестового окружения.
Как установить bicep-code-best-practices
Вручную: положить файлы
.github/instructions/bicep-code-best-practices.instructions.mdПоле applyTo задаёт, к каким файлам применять
Вручную: положить файлы
.claude/rules/bicep-code-best-practices.mdПоле paths во frontmatter ограничивает файлы: applyTo из источника → paths
AGENTS.md
Codex читает AGENTS.md: вставьте текст правила туда
Вручную: положить файлы
.cursor/rules/bicep-code-best-practices.mdcВо frontmatter: description, globs, alwaysApply. applyTo из источника → globs, иначе правило само не подключится
Вручную: положить файлы
.devin/rules/bicep-code-best-practices.mdВручную: положить файлы
.clinerules/bicep-code-best-practices.mdПо шагам, с командами для каждой платформы: AGENTS.md и CLAUDE.md: что это, кто читает и какой выбрать
Вопросы о bicep-code-best-practices
Как установить bicep-code-best-practices в GitHub Copilot?
Добавьте файл правила в проект по пути .github/instructions/bicep-code-best-practices.instructions.md.
Что делает bicep-code-best-practices?
Задаёт рекомендации для Bicep: как объявлять параметры, именовать ресурсы и связывать их между собой. Также запрещает помещать секреты и ключи в outputs.
К каким файлам применяется правило?
К файлам, подходящим под шаблон **/*.bicep.
Исходный текст
bicep-code-best-practices.instructions.md · MIT
--- description: 'Infrastructure as Code with Bicep' applyTo: '**/*.bicep' --- ## Naming Conventions - When writing Bicep code, use lowerCamelCase for all names (variables, parameters, resources) - Use resource type descriptive symbolic names (e.g., 'storageAccount' not 'storageAccountName') - Avoid using 'name' in a symbolic name as it represents the resource, not the resource's name - Avoid distinguishing variables and parameters by the use of suffixes ## Structure and Declaration - Always declare parameters at the top of files with @description decorators - Use latest stable API versions for all resources - Use descriptive @description decorators for all parameters - Specify minimum and maximum character length for naming parameters ## Parameters - Set default values that are safe for test environments (use low-cost pricing tiers) - Use @allowed decorator sparingly to avoid blocking valid deployments - Use parameters for settings that change between deployments ## Variables - Variables automatically infer type from the resolved value - Use variables to contain complex expressions instead of embedding them directly in resource properties ## Resource References - Use symbolic names for resource references instead of reference() or resourceId() functions - Create resource dependencies through symbolic names (resourceA.id) not explicit dependsOn - For accessing properties from other resources, use the 'existing' keyword instead of passing values through outputs ## Resource Names - Use template expressions with uniqueString() to create meaningful and unique resource names - Add prefixes to uniqueString() results since some resources don't allow names starting with numbers ## Child Resources - Avoid excessive nesting of child resources - Use parent property or nesting instead of constructing resource names for child resources ## Security - Never include secrets or keys in outputs - Use resource properties directly in outputs (e.g., storageAccount.properties.primaryEndpoints) ## Documentation - Include helpful // comments within your Bicep files to improve readability
© github · MIT · github/awesome-copilot