search

kubernetes-sigs / blob-csi-driver

Azure Blob Storage CSI driver
Apache License 2.0
123 stars 83 forks source link

chore(deps): bump sigs.k8s.io/cloud-provider-azure/pkg/azclient from 0.0.57 to 0.1.0 #1646

Closed dependabot[bot] closed 1 month ago

dependabot[bot] commented 1 month ago

Bumps sigs.k8s.io/cloud-provider-azure/pkg/azclient from 0.0.57 to 0.1.0.

Changelog

Sourced from sigs.k8s.io/cloud-provider-azure/pkg/azclient's changelog.

Release Versioning

Release source

There're two major code change sources for this project, either may push forward a new release for Kubernetes azure-cloud-controller-manager:

  1. Changes in Kubernetes cloud-controller-manager, which happens in Kubernetes repository Since this project dependes on Kubernetes cloud-controller-manager, we'll periodically sync changes from Kubernetes upstream repository. When upstream shipped a new release tag, we may consider publishing a new release

  2. Changes in Azure cloud provider, which happens directly in this repository Azure cloud provider also accepts new features and bug changes. In cases when a security fix is required or when the changes accumulated to certain amount, we may also consider publishing a new release, even if there is no change from Kubernetes upstream.

Versioning

This project is a Kubernetes component whereas the functionalities and APIs all go with Kubernetes upstream project, thus we will use same versioning mechanism of Kubernetes, with some subtle differences for Azure cloud provider and non-Kubernetes changes.

The basic rule is:

  1. Every release version follows Semantic Versioning, in the form of MAJOR.MINOR.PATCH
  2. For MAJOR.MINOR, it keeps same value as the Kubernetes upstream
  3. For PATCH, it is calculated independently:
    • If upstream Kubernetes has a new a patch release, which introduces change in cloud-controller-manager or any component we depend on, then sync the change and increase the PATCH number.
    • If any code change happens in Azure cloud provider or other dependency projects, which becomes eligible for a new release, then increase the PATCH number.

References:

Branch and version scheme

This project uses golang's vendoring mechanism for managing dependencies (see Dependency management for detail). When talking abount 'sync from Kubernetes upstream', it actually means vendoring Kubernetes repository code under the vendor directory.

During each sync from upstream, it is usually fine to sync to latest commit. But if there is a new tagged commit in upstream that we haven't vendored, we should sync to that tagged commit first, and apply a version tag correspondingly if applicable. The version tag mechanism is a bit different on master branch and releasing branch, please see below for detail.

The upstream syncing change should be made in a single Pull Request. If in some case, the upstream change causes a test break, then the pull requests should not be merged until follow up fix commits are added.

For example, if upstream change adds a new cloud provider interface, syncing the upstream change may raise a test break, and we should add the implementation (even no-op) in same pull request.

master branch

This is the main development branch for merging pull requests. When upgrading dependencies, it will sync from Kubernetes upstream's master branch.

Fixes to releasing branches should be merged in master branch first, and then ported to corresponding release branch.

Version tags:

  • X.Y.0-alpha.0
    • This is initial tag for a new release, it will be applied when a release branch is created. See below for detail
  • X.Y.0-alpha.W, W > 0
    • Those version tags are periodically created if enough change accumulated. It does not have direct mapping with X.Y.0-alpha.W in Kubernetes upstream

releasing branch

For release X.Y, the branch will have name release-X.Y. When upgrading dependencies, it will sync with Kubernetes upstream's release-X.Y branch. Release branch would be created when upstream release branch is created and first X.Y.0-beta.0 tag is applied.

Version tags:

  • X.Y.0-beta.0

... (truncated)

Commits
  • 6b4fee5 Merge pull request #132 from feiskyer/1.14-update
  • 8f4ab21 Update vendors for v1.14.0
  • c7352f8 Update kubernetes version to 1.14.0
  • ff0c8cf Merge pull request #131 from feiskyer/feature-gate
  • 5e93f20 Enable feature gate CSIInlineVolume for kube-controller-manager
  • 22a9e22 Merge pull request #129 from fseldow/master
  • 0a48ef6 Merge pull request #126 from jchauncey/fix-image-tag
  • 4aeaa69 fix: Allow IMAGE_TAG to be overridden
  • 81684fe Make autoscaler e2e test more stable
  • 7a3750c Merge pull request #123 from feiskyer/update-k8s-1.14
  • Additional commits viewable in compare view


Most Recent Ignore Conditions Applied to This Pull Request | Dependency Name | Ignore Conditions | | --- | --- | | sigs.k8s.io/cloud-provider-azure/pkg/azclient | [< 0.1, > 0.0.32] |

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.

Note: Dependabot was ignoring updates to this dependency, but since you've updated it yourself we've started tracking it for you again. 🤖

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)
k8s-ci-robot commented 1 month ago

Hi @dependabot[bot]. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.
k8s-ci-robot commented 1 month ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, dependabot[bot]

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/kubernetes-sigs/blob-csi-driver/blob/master/OWNERS)~~ [andyzhangx] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment