search

git-for-windows / git-for-windows-automation

A few GitHub workflows and support code to help with Git for Windows' day-to-day tasks
10 stars 9 forks source link

build(deps): bump azure/arm-deploy from 1 to 2 #72

Closed dependabot[bot] closed 4 months ago

dependabot[bot] commented 4 months ago

Bumps azure/arm-deploy from 1 to 2.

Release notes

Sourced from azure/arm-deploy's releases.

v2

Highlights

Full Changelog: https://github.com/Azure/arm-deploy/compare/v1.0.8...v2

Releasing v1.0.9

What's Changed

  • Updated node version from 12 to 16
  • Updated @​actions/core to ^1.10.0

Releasing v1.0.8

[Fix] Spacing bug in additional params

Releasing v1.0.7

Removed additionalArguments while validation step

Releasing v1.0.6

Added additionalArguments input.

All the extra parameters can be passed as string using additionalArguments.

additionalArguments: "--what-if --what-if-exclude-change-types Create Ignore --rollback-on-error"

Releasing v1.0.5

  1. Added failOnStdErr input Azure/arm-deploy#61

Releasing v1.0.4

  1. Fixed az-cli compat issue
  2. Updated test

Releasing v1.0.3 version

  • Fixing io streams issue
  • other readme changes

Releasing v1.0.2 version

No release notes provided.

arm-deploy@v1.0.1

A GitHub action to automate your workflow to deploy ARM templates.

Usage

Sample workflow to build and deploy a ARM template.

</tr></table>

... (truncated)

Changelog

Sourced from azure/arm-deploy's changelog.

Releasing a new version

Semanting versioning is used to release different versions of the action. Following steps are to be followed :

  1. Create a new branch for every major version.
    Example, releases/v1, releases/v2.
  2. For every minor and patch release for a major version, update the corresponding release branch.
    Example, for releasing v1.1.1, update releases/v1.
  3. Create tags for every new release (major/minor/patch).
    Example,v1.0.0. , v1.0.1, v2.0.1, etc. and also have tags like v1, v2 for every major version release.
  4. On releasing minor and patch versions, update the tag of the corresponding major version.
    Example, for releasing v1.0.1, update the v1 tag to point to the ref of the current release.
    The following commands are to be run on the release\v1 branch so that it picks the latest commit and updates the v1 tag accordingly : (Ensure that you are on same commit locally as you want to release.)
  • git tag -fa v1 -m "Update v1 tag"
  • git push origin v1 --force
Commits


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)