cwielenb/CNCF-Dataset huggingface dataset:
Project: DragonflyDB (App Definition and Development / Database)
File: build-from-source.md

Dragonfly runs on linux. We advise running it on linux version 5.11 or later but you can also run Dragonfly on older kernels as well. :warning: Dragonfly releases are compiled with LTO (link time optimization): Depending on the workload this can notably improve performance. If you want to benchmark Dragonfly or use it in production, you should enable LTO by giving `blaze.sh` the `-DCMAKECXXFLAGS="-flto"` argument. On Debian/Ubuntu: ```bash sudo apt install ninja-build libunwind-dev libboost-fiber-dev libssl-dev \ autoconf-archive libtool cmake g++ libzstd-dev bison libxml2-dev ``` On Fedora: ```bash sudo dnf install -y automake boost-devel g++ git cmake libtool ninja-build libzstd-devel \ openssl-devel libunwind-devel autoconf-archive patch bison libxml2-devel libstdc++-static ``` On openSUSE: ```bash sudo zypper install automake boost-devel gcc-c++ git cmake libtool ninja libzstd-devel \ openssl-devel libunwind-devel autoconf-archive patch bison libxml2-devel \ libboostcontext-devel libboostsystem-devel ``` ```bash git clone --recursive https://github.com/dragonflydb/dragonfly && cd dragonfly ``` ```bash ./helio/blaze.sh -release cd build-opt && ninja dragonfly ``` ```bash ./dragonfly --alsologtostderr ``` Dragonfly DB will answer to both `http` and `redis` requests out of the box! You can use `redis-cli` to connect to `localhost:6379` or open a browser and visit `http://localhost:6379` Connect with a redis client ```bash redis-cli 127.0.0.1:6379> set hello world OK 127.0.0.1:6379> keys * 1) "hello" 127.0.0.1:6379> get hello "world" 127.0.0.1:6379> ``` Continue being great and build your app with the power of DragonflyDB!
Project: ArangoDB (App Definition and Development / Database)
File: outcome_throw_as_system_error_with_payload_std_enum.md

+++ title = "`void outcomethrowassystemerrorwithpayload(ErrorCodeEnum &&)`" description = "Specialisation of `outcomethrowassystemerrorwithpayload()` for input types where `std::iserrorcodeenum<ErrorCodeEnum>` or `std::iserrorconditionenum<ErrorCodeEnum>` is true." +++ A specialisation of `outcomethrowassystemerrorwithpayload()` for types where `std::iserrorcodeenum<ErrorCodeEnum>` or `std::iserrorconditionenum<ErrorCodeEnum>` is true. This executes {{% api "BOOSTOUTCOMETHROWEXCEPTION(expr)" %}} with a {{% api "std::systemerror" %}} constructed from the result of the ADL discovered free function `makeerrorcode(ErrorCodeEnum)`. Overridable: Argument dependent lookup. Requires: Either {{% api "std::iserrorcodeenum<T>" %}} or {{% api "std::iserrorconditionenum<T>" %}} to be true for a decayed `ErrorCodeEnum`. Namespace: `std` Header: `<boost/outcome/std_result.hpp>`
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.2.7.8.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | Remove references to Guava Objects.toStringHelper | Major | . | Jonathan Eagles | Jonathan Eagles | | | Test failure TestSSLHttpServer.testExcludedCiphers with TLS\ECDHE\RSA\WITH\AES\128\CBC\_SHA256 cipher suite | Major | common | Gabor Bota | Szilard Nemeth | | | Restore previous state in container-executor after failure | Major | . | Jim Brennan | Jim Brennan |
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: certs_custom.md

+++ title = "Custom Certificates" description = "Handling custom (CA) certificates" gh_repo = "habitat" [menu] [menu.habitat] title = "Custom Certificates" identifier = "habitat/reference/certs-custom Custom Certs" parent = "habitat/reference" +++ Many enterprise environments use custom certificates (for example, self-signed). For example, an on-premises Chef Habitat Builder Depot might have a self-signed SSL certificate. Attempting to perform an operation using the Habitat client to communicate with a service that has a custom certificate can produce an error, such as: ```output the handshake failed: The OpenSSL library reported an error: error:14090086:SSL routines:ssl3getservercertificate:certificate verify failed:s3clnt.c:1269:: unable to get local issuer certificate ``` One option to remediate this error is to define a `SSLCERTFILE` environment variable pointing to the custom certificate path before performing the client operation. The Habitat 0.85.0 release in September 2019 improved the handling of custom certificates. Now Habitat knows to look for custom certificates in the `~/.hab/cache/ssl` directory, which is `/hab/cache/ssl` when you are running as root. Copying multiple certificates--for example, a self-signed certificate and a custom certificate authority certificate--to the Chef Habitat cache directory makes them automatically available to the Habitat client. The `/hab/cache/ssl` directory is also available inside a Habitat Studio. As long as the certificates are inside the cache directory before you enter the Studio, you'll also find them inside the Studio. In addition, if you've set the `SSLCERTFILE` environment variable, you'll also find both it and the file that it points to inside the Studio`/hab/cache/ssl` directory. Note: The `cert.pem` file name is reserved for Habitat. Do not use `cert.pem` as a file name when copying certs into the cache directory.
Project: ShardingSphere (App Definition and Development / Database)
File: show-encrypt-algorithm-plugins.en.md

+++ title = "SHOW ENCRYPT ALGORITHM PLUGINS" weight = 4 +++ The `SHOW ENCRYPT ALGORITHM PLUGINS` syntax is used to query all the implementations of the interface `org.apache.shardingsphere.encrypt.spi.EncryptAlgorithm`. {{< tabs >}} {{% tab name="Grammar" %}} ```sql showEncryptAlgorithmPlugins ::= 'SHOW' 'ENCRYPT' 'ALGORITHM' 'PLUGINS' ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} | Columns | Description | |--|--| | type | type | | type_aliases | type aliases | | description | description | Query all the implementations for `org.apache.shardingsphere.encrypt.spi.EncryptAlgorithm` interface ```sql SHOW ENCRYPT ALGORITHM PLUGINS ``` ```sql SHOW ENCRYPT ALGORITHM PLUGINS; ++--+-+ | type | type_aliases | description | ++--+-+ | AES | | | | MD5 | | | ++--+-+ 2 rows in set (0.06 sec) ``` `SHOW`, `ENCRYPT`, `ALGORITHM`, `PLUGINS`
Project: Pravega (App Definition and Development / Streaming & Messaging)
File: roadmap.md

<!-- Copyright Pravega Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> The following items are new features that we wish to build in upcoming Pravega releases. Please reach out on the Pravega channels if you're interested in picking one of these up. Reduce and control Pravega resources: Minimize resource footprint for Edge environments. Plugable consensus service (Zookeeper, Etcd). Ability to define throughput quotas and other QoS guarantees. Enrich Pravega ecosystem and language support: Kafka compatibility. Sensor collector improvements. Data replicator. New client bindings and add capabilities to existing ones (e.g., NodeJS, Go, C#). Flexible management of Pravega streams: Zone/region awareness in Pravega. Improve Pravega's Long-Term Storage support: Policy-driven tiering configuration for Streams/Scopes. Support for additional Long-Term Storage backends. Allow Bookkeeper-only deployment (for both Write-Ahead Log and Long-Term Storage). Increase support for data types and data reduction: Configurable Long-Term Storage formats. New serializers (compression, specialized data formats).
Project: StarRocks (App Definition and Development / Database)
File: replicanum.md

:::note If a StarRocks cluster in a staging environment contains only one BE, the number of replicas can be set to `1` in the `PROPERTIES` clause, such as `PROPERTIES( "replicationnum" = "1" )`. The default number of replicas is 3, which is also the number recommended for production StarRocks clusters. If you want to use the default number, you do not need to configure the `replicationnum` parameter. :::
Project: StarRocks (App Definition and Development / Database)
File: to_date.md

displayed_sidebar: "English" Converts a DATETIME value into a date. ```Haskell DATE TO_DATE(DATETIME datetime) ``` ```Plain Text MySQL > select to_date("2020-02-02 00:00:00"); +--+ | to_date('2020-02-02 00:00:00') | +--+ | 2020-02-02 | +--+ ``` TO_DATE
Project: ShardingSphere (App Definition and Development / Database)
File: shardingsphere-jdbc-quick-start.en.md

+++ pre = "<b>2.1. </b>" title = "ShardingSphere-JDBC" weight = 1 +++ There are two ways you can configure Apache ShardingSphere: `Java` and `YAML`. Developers can choose the preferred method according to their requirements. Currently only Java language is supported. The development environment requires Java JRE 8 or later. Rules configuration. Please refer to for more details. Import Maven dependency ```xml <dependency> <groupId>org.apache.shardingsphere</groupId> <artifactId>shardingsphere-jdbc</artifactId> <version>${latest.release.version}</version> </dependency> ``` Notice: Please change `${latest.release.version}` to the actual version. Create YAML configuration file ```yaml databaseName (?): mode: dataSources: rules: !FOO_XXX ... !BAR_XXX ... props: key1: value1 key2: value2 ``` Take `spring boot` as an example, edit `application.properties`. ```properties spring.datasource.driver-class-name=org.apache.shardingsphere.driver.ShardingSphereDriver spring.datasource.url=jdbc:shardingsphere:classpath:xxx.yaml ``` For details, see .
Project: Chef InSpec (Provisioning / Security & Compliance)
File: control-eval.md

In the early days of Chef InSpec / ServerSpec, controls were called "rules". Throughout various places in the code, the word "rule" is used to mean "control". Make the mental substitution. Chef InSpec supports reading profiles from tarballs, local files, git repos, etc. So, don't count on local file reading; instead it uses a special source reader to obtain the contents of the files. Profile context gets instantiated as soon as the Profile gets created. 0 Inspec::ProfileContext.initialize(profileid#String, backend#Inspec::Backend, conf#Hash) at inspec/lib/inspec/profilecontext.rb:20 -- #1 Class.new(*args) at inspec/lib/inspec/profile_context.rb:13 -- #4 Class.new(*args) at inspec/lib/inspec/profile.rb:61 -- #10 Array.each at inspec/lib/inspec/cli.rb:283 When run method of the runner gets called, it loads control which instantiates the controlevalcontext object and creates dsl, and the adds profile_context as dsl class methods -- #2 Module.initialize at inspec/lib/inspec/profile_context.rb:218 -- #3 Class.new(*args) at inspec/lib/inspec/profile_context.rb:218 -- #9 Hash.each at inspec/lib/inspec/profile.rb:216 -- #12 Array.each at inspec/lib/inspec/runner.rb:101 So, if you have a control file with `title` in it, that will call the title method that was defined . Importantly, this also includes the `control` DSL keyword, and also the `describe` keyword (used for bare describes). Each control gets registerd and the terminology switches from `control` to `rule` The control context class also gets extended with the resource DSL, so anything in the source code for the control can use the resource DSL. This includes all resource names, but importantly, the `describe` DSL keyword. Finally, Inspec::Rule provides the control DSL - impact, title, desc, ref, and tags. See `https://github.com/inspec/inspec/blob/main/lib/inspec/rule.rb#L46`. We're now in two levels of instance eval'ing - the file is gradually being eval'd against the profile context and the current control's block is being instance eval'd against a control context. At this stage, control-level metadata (impact, title, refs, tags, desc) are evaluated and set as instance vars on the control. Any "loose" ruby in the control is also executed at this point. And, the describe and describe.one blocks are executed. Using the method registercontrol (dynamically defined on the control eval context), we check for various skip conditions. If none of them apply, the control is then registered with the profile context using registerrule. main job is to determine the full ID of the control (within the context of the profile) and either add it to the controls list, or (if another control with the same ID exists), merge it. (This is where overriding happens). Note: can skip a control with: Inspec::Rule.setskiprule(control, msg)
Project: YugabyteDB (App Definition and Development / Database)
File: jsonb-extract-path.md

title: jsonbextractpath() and jsonextractpath() [JSON] headerTitle: jsonbextractpath() and jsonextractpath() linkTitle: jsonbextractpath() description: Provide identical functionality to the "#>" operator. menu: v2.18: identifier: jsonb-extract-path parent: json-functions-operators weight: 130 type: docs Purpose: Provide the identical functionality to the operator. Signature For the `jsonb` variant: ``` input value: jsonb, VARIADIC text return value: jsonb ``` The invocation of can be mechanically transformed to use `jsonbextractpath()` by these steps: Add the function invocation with its required parentheses. Replace `#>` with a comma. Write the path as a comma-separated list of terms, where both integer array indexes and key-value keys are presented as `text` values, taking advantage of the fact that the function is variadic). This `DO` block shows the invocation of `#>` and `jsonbextractpath()` vertically to help visual comparison. ``` do $body$ declare j constant jsonb := '[1, {"x": [1, true, {"a": "cat", "b": "dog"}, 3.14159], "y": true}, 42]'; jsub_1 constant jsonb := j #> array['1', 'x', '2', 'b']; jsub2 constant jsonb := jsonbextract_path(j, '1', 'x', '2', 'b'); expected_jsub constant jsonb := '"dog"'; begin assert (jsub1 = expectedjsub) and (jsub2 = expectedjsub), 'unexpected'; end; $body$; ``` Notice that even though `jsonbextractpath()`is variadic, each step that defines the path must be presented as a convertible SQL `text`, even when its meaning is a properly expressed by a SQL `integer`. The function form is more verbose than the operator form. Moreover, the fact that the function is variadic makes it impossible to invoke it statically (in PL/pgSQL code) when the path length isn't known until run time. There is, therefore, no reason to prefer the function form to the operator form.
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: git-integration.md

Git is integrated into Monokle Desktop to tackle GitOps seamlessly within the application. If you work within a DevOps culture our Git integration provides advantages for you and your team by keeping a history of changes made to your applications stored in Git to ensure access to a reliable audit trail of your changes. You can use a Git repository URL to start a new project. The repository will be cloned to the selected location and then opened into Monokle Desktop. This allows multiple colleagues to debug, validate, and diff all of your configuration files taking full advantage of all of the features of Monokle Desktop to achieve your desired state while also maintaining clear control of your version changes. In the header, next to the Project Selector, a dropdown menu appears whenever Monokle Desktop detects the current project has a Git repository. With the Branch Selector, you can search through all of your local and remote branches in more detail while having the option of creating new local branches. In the left menu of Monokle Desktop, there is a dedicated Git panel. This panel contains the Changelist which is grouped into two lists: Staged and Unstaged files. By clicking on each file, you will immediately see the differences between the old version and the newer, modified version with valuable insight as you work to achieve your desired state. Using the checkboxes, select multiple files to apply the same action at once. After staging some of the files, you can commit the changes directly via Monokle Desktop. Once staged changes have been committed, unpublished branches can be directly published to remote through Monokle Desktop simply push your commits.
Project: KICS (Provisioning / Security & Compliance)
File: 07f7134f-9f37-476e-8664-670c218e4702.md

title: PostgreSQL Log Disconnections Not Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 07f7134f-9f37-476e-8664-670c218e4702 Query name: PostgreSQL Log Disconnections Not Set Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Observability URL: Make sure that for PostgreSQL Database, server parameter 'log_disconnections' is set to 'ON'<br> ```tf title="Positive test num. 1 - tf file" hl_lines="19 12 5" resource "azurermpostgresqlconfiguration" "positive1" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "off" } resource "azurermpostgresqlconfiguration" "positive2" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "Off" } resource "azurermpostgresqlconfiguration" "positive3" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "OFF" } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermpostgresqlconfiguration" "negative1" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "on" } resource "azurermpostgresqlconfiguration" "negative2" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "On" } resource "azurermpostgresqlconfiguration" "negative3" { name = "log_disconnections" resourcegroupname = data.azurermresourcegroup.example.name servername = azurermpostgresql_server.example.name value = "ON" } ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: nemo-runner.md

title: "Nemo Runner Roadmap" <!-- Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> This roadmap is in progress. In the meantime, here are available resources: - JIRA: /
Project: KICS (Provisioning / Security & Compliance)
File: a99130ab-4c0e-43aa-97f8-78d4fcb30024.md

title: Encryption On Managed Disk Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: a99130ab-4c0e-43aa-97f8-78d4fcb30024 Query name: Encryption On Managed Disk Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Encryption URL: Ensure that the encryption is active on the disk<br> ```tf title="Positive test num. 1 - tf file" hl_lines="10 18" resource "azurermmanageddisk" "positive1" { name = "acctestmd" location = "West US 2" resourcegroupname = azurermresourcegroup.example.name storageaccounttype = "Standard_LRS" create_option = "Empty" disksizegb = "1" encryption_settings = { enabled = false } tags = { environment = "staging" } } resource "azurermmanageddisk" "positive2" { name = "acctestmd" location = "West US 2" resourcegroupname = azurermresourcegroup.example.name storageaccounttype = "Standard_LRS" create_option = "Empty" disksizegb = "1" tags = { environment = "staging" } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermmanageddisk" "negative1" { name = "acctestmd" location = "West US 2" resourcegroupname = azurermresourcegroup.example.name storageaccounttype = "Standard_LRS" create_option = "Empty" disksizegb = "1" encryption_settings = { enabled = true } tags = { environment = "staging" } } ```
Project: external-secrets (Provisioning / Security & Compliance)
File: release.md

ESO and the ESO Helm Chart have two distinct lifecycles and can be released independently. Helm Chart releases are named `external-secrets-x.y.z`. The external-secrets project is released on a as-needed basis. Feel free to open a issue to request a release. When doing a release it's best to start with with the , it has a checklist to go over. Note: when releasing multiple versions, make sure to first release the "old" version, then the newer version. Otherwise the `latest` documentation will point to the older version. Also avoid to release both versions at the same time to avoid race conditions in the CI pipeline (updating docs, GitHub Release, helm chart release). Run `Create Release` Action to create a new release, pass in the desired version number to release. choose the right `branch` to execute the action: use `main` when creating a new release. Use `release-x.y` when you want to bump a LTS release. make sure that CI on the relevant branch has completed the docker build/push jobs. Otherwise an old image will be promoted. GitHub Release, Changelog will be created by the `release.yml` workflow which also promotes the container image. update Helm Chart, see below update OLM bundle, see Update `version` and/or `appVersion` in `Chart.yaml` and run `make helm.docs helm.update.appversion helm.test.update helm.test` push to branch and open pr run `/ok-to-test-managed` commands for all cloud providers merge PR if everyhing is green CI picks up the new chart version and creates a new GitHub Release for it create/merge into release branch on a `minor` release: create a new branch `release-x.y` on a `patch` release: merge main into `release-x.y` In order to make the latest release available to we need to create a bundle and open a PR in the repository. To create a bundle first increment the `VERSION` in the Makefile as described above. Then run the following commands in the root of the repository: ```bash git clone https://github.com/external-secrets/external-secrets-helm-operator cd external-secrets-helm-operator export VERSION=x.y.z sed -i "s/^VERSION ?= .*/VERSION ?= ${VERSION}/" Makefile make prepare-stable-release ATTACHIMAGEDIGESTS=0 ``` Check the generated files in the `bundle/` directory. If they look good add & commit them, open a PR against this repository. You can always use the page to preview the generated CSV. ```bash git status git add . git commit -s -m "chore: bump version xyz" git push ``` Once the PR is merged and the image build job on `main` has completed, we need create a pull request against both community-operators repositories. There's a make target that does the heavy lifting for you: ```bash make attach-image-digests make bundle-operatorhub ``` This command will add/commit/push and open pull requests in the respective repositories.