Environment custom branch policies support type ('branch', 'tag')

[goruha]

What

• Added type support for environment deployment_branch_policy custom branches.

Why

• Environment deployment_branch_policy supports custom branches type - branch or tag. The type is an option parameter that sets branch by default. These changes allow us to specify deployment_branch_policy for tag

Config example

environments:
  - name: development
    deployment_branch_policy:
      custom_branches:
        - dev/*
        - name: release/*
          type: branch
        - name: v*
          type: tag

You can specify custom_branches list item as string for back-compatibility or as object

name: `string`
type: `branch | tag`

Releated links

• Create a deployment branch policy API

[vercel[bot]]

@goruha is attempting to deploy a commit to the Repository Settings Team on Vercel.

A member of the Team first needs to authorize it.

[goruha]

@julekirk @mayliang021 @travi may I have a review pls?

[travi]

supporting tag targets feels separate from what makes sense under "custom_branches". would a separate section for tags be a better fit?

[goruha]

@travi

supporting tag targets feels separate from what makes sense under "custom_branches". would a separate section for tags be a better fit?

Yeah, the separate settings for tags look better. However, GitHub API does not have this separation, and we should follow the GitHub API structure. Mapping the GitHub API contract to settings.yml solves the lack of documentation - you can always reference GitHub API to see what fields are available. So I advocate to go with solution provided in the PR

https://docs.github.com/en/rest/deployments/branch-policies?apiVersion=2022-11-28#create-a-deployment-branch-policy

[goruha]

@travi can we have this PR merged?

[travi]

Yeah, the separate settings for tags look better. However, GitHub API does not have this separation, and we should follow the GitHub API structure. Mapping the GitHub API contract to settings.yml solves the lack of documentation - you can always reference GitHub API to see what fields are available.

in general, i agree. however, as mentioned in the docs for the environments plugin, we already deviate a bit, so that is the reason that gave me pause here. since even the github api still uses the branches terminology for this, i think i'm ok with proceeding with the proposed approach

[github-actions[bot]]

:tada: This PR is included in version 3.1.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: