rebase: bump ceph/ceph-csi from 28dc64dcae3cec8d11d84bdf525bda0ef757c688 to 29aecd345fd0de42da16a000e8d4e18ee0be18df

[dependabot]

Bumps ceph/ceph-csi from 28dc64d to 29aecd3.

Changelog

Sourced from ceph/ceph-csi's changelog.

Ceph CSI driver Release Process

• Ceph CSI driver Release Process
  • Introduction
  • Versioning
  • Tagging repositories
  • Release process [TBD]

Introduction

This document provides details about Ceph CSI driver release process.

Versioning

The Ceph CSI driver project uses semantic versioning for all releases. Semantic versions are comprised of three fields in the form:

MAJOR.MINOR.PATCH

For examples: 1.0.0, 1.0.0-rc.2.

Semantic versioning is used since the version number is able to convey clear information about how a new version relates to the previous version. For example, semantic versioning can also provide assurances to allow users to know when they must upgrade compared with when they might want to upgrade:

• When PATCH increases, the new release contains important security fixes, general bug fixes and an upgrade is recommended.

The patch field can contain extra details after the number. Dashes denote pre-release versions.1.0.0-rc.2 in the example denotes the second release candidate for release 1.0.0.

• When MINOR increases, the new release adds new features and it must be backward compatible.

• When MAJOR increases, the new release adds new features, bug fixes, or both and which changes the behavior from the previous release (maybe backward incompatible).

Tagging repositories

The tag name must begin with "v" followed by the version number, conforming to the versioning requirements (e.g. a tag of v1.0.0-rc2 for version 1.0.0-rc2). This tag format is used by the GitHub action

... (truncated)

Commits

• 29aecd3 cephfs: return correct error msg
• 1edceeb doc: reset PendingReleaseNotes.md
• c76338c doc: add a release note about "Slow GRPC" logs
• ed3c916 doc: added notes about --logslowopinterval cmd arg
• d250be4 helm: added logSlowOperationInterval value to cephfs and rbd charts
• 7a727c2 util: added logs for slow gRPC calls
• 56d08e1 ci: Harden GitHub Actions
• 25d4186 rebase: bump google.golang.org/grpc from 1.66.0 to 1.66.2
• a6d8954 rebase: bump github.com/hashicorp/vault/api
• See full diff in compare view

You can trigger a rebase of this PR 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 <dependency name> 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)

[nixpanic]

I don't think we want this. Every time there is a change merged, it will get updated?

This should just point to the files in devel branch. @Nikhil-Ladha do you want to make that change and make sure that the security scanner doesn't complain about it in the future?

[Nikhil-Ladha]

I don't think we want this. Every time there is a change merged, it will get updated?

It will get updated at an interval of 1 week.

This should just point to the files in devel branch. @Nikhil-Ladha do you want to make that change and make sure that the security scanner doesn't complain about it in the future?

I am not sure if there is a way to bypass this for security scanner, there is an open feature plan for this with no update as of now: https://github.com/orgs/ossf/projects/24/views/1?pane=issue&itemId=55431256