С помощью Bitbucket и Bamboo я мог отслеживать Bamboo по каждой ветки функций и запускать тесты для каждой из них, чтобы во время запроса на извлечение я мог видеть, прошла ли ветвь свои модульные тесты.
С AWS CodePipeline я не могу сказать, смогу ли я отследить каждую ветвь компонента и выполнить тесты на них перед слиянием.
Это возможно? Если это так, пожалуйста, укажите мне на документацию.
К сожалению, не представляется возможным инициировать сборки из нескольких веток в CodePipeline. Это немного удивляет меня, так как любой другой инструмент CI, который я использовал, предлагает эту функциональность прямо из коробки (GitLabCI, TravisCI, CircleCI, Bitbucket Pipelines, TeamCity) или с проверенным в бою плагином (Jenkins).
Однако на данный момент, возможно, существует несколько способов обойти это ограничение, которое я нашел и могу использовать /adapt: https://github.com/nicolai86/awesome-codepipeline-ci.
У меня точно такая же проблема, я сейчас над ней работаю. :)
Дальнейший обзор показывает, что с облачной информацией вы можете выбрать ветку, которая отслеживает дорожки CodePipeline,
AWS CodeCommit (
CodeCommit)
- PollForSourceChanges¹ (необязательно)
- RepositoryName (обязательно)
- BranchName (обязательно)
Вы можете увидеть пример полного шаблона, но этап CodePipeline выглядит,
Name: CheckoutSourceTemplate
ActionTypeId:
Category: Source
Owner: AWS
Version: 1
Provider: CodeCommit
Configuration:
PollForSourceChanges: True
RepositoryName: !GetAtt [PipelineRepo, Name]
BranchName: master
OutputArtifacts:
- Name: TemplateSource
RunOrder: 1
С CodeCommit Repo, вы можете создать Triggers, которые могут использовать эти триггеры для запустить функцию лямбда,
Вы можете настроить функции лямбда, создав триггер в консоли Lambda как часть функции. Это самый простой метод, поскольку триггеры, созданные в консоли Lambda, автоматически включают разрешения, необходимые для AWS CodeCommit для вызова функции Lambda. Если вы создаете триггер в AWS CodeCommit, вы должны включить политику, позволяющую AWS CodeCommit вызывать функцию. Для получения дополнительной информации см. Создать триггер для существующей функции лямбда и Пример 2. Создание политики для интеграции лямбда AWS.
Итак, что может произойти, это настроить шаблон CloudFormation, как указано выше, для отслеживания основной ветки. Затем введите триггер CodeCommit для изменений в репозитории и вызовите функцию Lambda, которая использует Boto3 для get_pipeline для получения магистрального конвейера.
Затем используйте update_pipeline или create_pipeline добавить этап в существующий магистральный конвейер или создать совершенно новый конвейер, который отслеживает желаемые дополнительные ветки.
Таким образом, CodePipeline может отслеживать ветки функций полезным способом.
Я искал решение именно этой проблемы. В конце концов я решил, что CodeBuild, который может быть запущен из регулярного выражения ветки, начинает конвейер, передавая архив к определенному ключу S3. В моем случае у меня также было, чтобы CodeBuild выполнял весь процесс сборки/тестирования, но вы также можете настроить CodeBuild так, чтобы он только извлекал код и нажимал на него клавишу S3, которая запускает вашу CodePipeline.
Вот часть примера конфигурации CodeBuild, соответствующей 2 веткам: 
Затем я установил артефакт CodeBuild для перехода к одному ключу в одной корзине.
Затем я устанавливаю CodePipeline с источником Amazon S3, указывающим на тот же ключ/корзину.
Я столкнулся с этой же проблемой и закончил тем, что написал пошаговое руководство по двум различным способам сделать это в зависимости от вашего исходного хранилища.
Как отслеживать несколько веток Git в AWS CodePipeline
[TL; DR]
GitHub или Bitbucket: создайте проект CodeBuild с помощью webhook и используйте S3 в качестве источника.
CodeCommit: создайте лямбда-триггер, который создает новый конвейер для каждой ветки.