The `github.event.label.name` was replaced by
`github.event.pull_request.label` in PR #3862. It seems that the value
always is `null`, which causes the pull-request-commenter to skip the
events for `ok-to-test` label additions. By using the original
`github.event.label.name`, things work again as expected.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
With the updates to the pull-request-commenter, all strings were placed
within `'` to prevent syntax issues. It seems that
`github.event.pull_request.merged` really is a boolean (or `null`), and
not a string.
Doc: https://docs.github.com/en/webhooks-and-events/ ("payloads" section)
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Backslashes (`\`) cause issues in the `if` statment with GitHub
Workflows.
Unexpected symbol: '\'. Located at position 53 within expression:
(github.event.pull_request.label == 'ok-to-test' && \
Using the `>` YAML syntax to replace linebreaks with spaces should
address this problem.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
The `ok-to-test` label does not work anymore, and the GitHub Workflow
contains the following error:
The workflow is not valid.
.github/workflows/pull-request-commentor.yaml (Line: 15, Col: 9):
Unrecognized named-value: 'ok-to-test'.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
The `Add comment` workflow was triggered only
when labels were added to the pr and failed
to be run on prs which were created with the
required label.
This commit makes sure the workflow is triggered
on pr creation too.
Signed-off-by: Rakshith R <rar@redhat.com>
Installing Helm fails often in the CI. The Helm documentation does not
point to `https://git.io/get_helm.sh` anymore, but to a location on
GitHub. To make it easier to update the location in the future, it has
now been added to `build.env`, just like the `HELM_VERSION`.
See-also: https://helm.sh/docs/intro/install/
Signed-off-by: Niels de Vos <ndevos@ibm.com>
fix bug that make provisioner get dup affinities
when deploy helm chart ceph-csi-rbd and ceph-csi-cephfs.
Signed-off-by: DashJay <45532257+dashjay@users.noreply.github.com>
The original Mergifyio/gha-mergify-merge-queue-labels-copier@main
contains `startsWith()` that has the arguments reversed. This prevents
the action from working as intended.
See-also: https://docs.github.com/en/actions/learn-github-actions/expressions
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Setting an empty `labels:` fails to work as intended, no labels get
copied ad all. Now setting the `ci/skip/..` labels, as those are most
important for speeding up merging.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Author of mergifyio created pr is mergify[bot].
It needs the suffix `[bot]` for the condition
to be evaluated to true.
Signed-off-by: Rakshith R <rar@redhat.com>
It seems that some PRs still get rebased by Mergify, whereas others get
tested for the **merge queue** by creating a new temporary PR. In both
cases the `ok-to-test` label should get set automatically.
Fixes: c4d372e (ci: automatically add `ok-to-test` to PRs created by Mergify)
Signed-off-by: Niels de Vos <ndevos@ibm.com>
When Mergify creates a PR, the `ok-to-test` label needs to be added
before CI runs. Not all PRs need complete testing, and they may have
some `ci/skip/..` labels too. With this new GitHub Workflow, the labels
get copied from the original PR into the newly created PR.
See-also: https://github.com/Mergifyio/mergify/discussions/5088
Signed-off-by: Niels de Vos <ndevos@ibm.com>
golangci-lint reports that `grpc_middleware.WithUnaryServerChain` is
deprecated and `google.golang.org/grpc.ChainUnaryInterceptor` should be
used instead.
Signed-off-by: Niels de Vos <ndevos@ibm.com>
Mergify does not automatically rebase PRs that are queued for merging
(anymore?). Instead, it creates a new draft PR that is expected to get
tested by the CI. At the moment someone needs to add the `ok-to-test`
label to the PR. This is cumbersome and can cause delays in the merge
process.
The configuration for Mergify now includes a rule that any PR created by
Mergify, will automatically get the `ok-to-test` label. This should make
it easier to get PR merged.
See-also: #3796
Signed-off-by: Niels de Vos <ndevos@ibm.com>
CephNFS can enable different security flavours for exported volumes.
This can be configured in the optional `secTypes` parameter in the
StorageClass.
Signed-off-by: Niels de Vos <ndevos@redhat.com>
By default, `cryptsetup luksFormat` uses Argon2i as Password-Based Key
Derivation Function (PBKDF), which not only has a CPU cost, but also a memory
cost (to make brute-force attacks harder).
The memory cost is based on the available system memory by default, which in
the context of Ceph CSI can be a problem for two reasons:
1. Pods can have a memory limit (much lower that the memory available on the
node, usually) which isn't taken into account by `cryptsetup`, so it can get
OOM-killed when formating a new volume;
2. The amount of memory that was used during `cryptsetup luksFormat` will then
be needed for `cryptsetup luksOpen`, so if the volume was formated on a node
with a lot of memory, but then needs to be opened on a different node with
less memory, `cryptsetup` will get OOM-killed.
This commit sets the PBKDF memory limit to a fixed value to ensure consistent
memory usage regardless of the specifications of the nodes where the volume
happens to be formatted in the first place.
The limit is set to a relatively low value (32 MiB) so that the `csi-rbdplugin`
container in the `nodeplugin` pod doesn't require an extravagantly high memory
limit in order to format/open volumes (particularly with operations happening
in parallel), while at the same time not being so low as to render it
completely pointless.
Signed-off-by: Benoît Knecht <bknecht@protonmail.ch>
Currently the Ceph-CSI community is on the 'free' Slack instance at
https://cephcsi.slack.com. The Ceph project uses a Slack instance that
we can use for Ceph-CSI as well. In order to integrate more with other
Ceph projects, we should ideally be active on the same Slack instance.
For now, we have `#ceph-csi` as only channel on the
https://ceph-storage-slack.com, we can add more channels if needed.
See-also: https://ceph.io/en/community/connect/
Signed-off-by: Niels de Vos <ndevos@ibm.com>
