cwielenb/CNCF-Dataset huggingface dataset:
Project: Aserto (Provisioning / Security & Compliance)
File: README.md

](https://pkg.go.dev/github.com/aserto-dev/runtime) ](https://goreportcard.com/report/github.com/aserto-dev/runtime) The "runtime" project is a library that sits on top of . The goal of the project is to allow you to quickly write code that builds, runs or tests OPA policies. It uses the options pattern to facilitate construction of `Runtime` instances specific to your needs. You can start super simple, using it just to build some rego into a bundle, or you can get more complex, using it to start a runtime with plugins, built-ins and other features. ```shell go get -u github.com/aserto-dev/runtime ``` ```go // Create a runtime r, cleanup, err := runtime.NewRuntime(ctx, &logger, &runtime.Config{}) if err != nil { return errors.Wrap(err, "failed to create runtime") } defer cleanup() // Use the runtime to build a bundle from the current directory return r.Build(runtime.BuildParams{ OutputFile: "my-bundle.tar.gz", }, ".") ``` You can find a more complete example in the directory. Based on the awesome .
Project: YDB (App Definition and Development / Database)
File: linux.md

| Version | Release date | Download | Changelog | : | : | : | : v23.4 v.23.4.11 | 14/05/2024 | v23.3 v.23.3.17 | 14/12/2023 | v.23.3.13 | 12/10/2023 | | v23.2 v.23.2.12 | 14/08/2023 | | v23.1 v.23.1.26 | 05/05/2023 | | v22.5 v.22.5.10 | 09/02/2023 | | v22.4 v.22.4.44 | 28/11/2022 | | v.22.4.31 | 23/10/2022 | v.22.4.30 | 09/10/2022 | v.22.4.21 | 03/10/2022 | v22.2 v.22.2.47 | 07/07/2022 | v.22.2.40 | 16/06/2022 | v.22.2.39 | 15/06/2022 | v.22.2.31 | 07/06/2022 | v.22.2.22 | 18/04/2022 | v.22.2.5 | 14/02/2022 |
Project: Meshery (Provisioning / Automation & Configuration)
File: 09-29-2022-16-01-09_55299d76.md

timestamp: "2022-09-29 16:00:56 UTC Thu" meshery-component: meshery-consul meshery-component-version: edge meshery-server-version: "v0.6.9" k8s-distro: minikube k8s-version: "v1.21.5" service-mesh: Consul service-mesh-version: "v0.48.0" tests: consul-client: null consul-server: null overall-status: "failing"
Project: ArangoDB (App Definition and Development / Database)
File: default_policy.md

+++ title = "`default_policy<T, EC, EP>`" description = "A type alias to a no-value policy selected based on traits matching of `T`, `EC` and `EP`." +++ A type alias to a no-value policy selected based on traits matching of `T`, `EC` and `EP`. It is defined as follows: If `EC` and `EP` is `void`, choose {{% api "terminate" %}}. If {{% api "iserrorcodeavailable<T>" %}} true for `EC`, choose {{% api "errorcodethrowassystemerror<T, EC, EP>" %}} for `basicoutcome` or {{% api "errorcodethrowassystemerror<T, EC, void>" %}} for `basic_result`. If {{% api "isexceptionptravailable<T>" %}} true for `EC` or `EP`, choose {{% api "exceptionptrrethrow<T, EC, EP>" %}} for `basicoutcome` or {{% api "exceptionptrrethrow<T, EC, void>" %}} for `basic_result`. Else choose {{% api "failtocompile_observers" %}}, which fails the build with a useful message. Namespace: `BOOSTOUTCOMEV2_NAMESPACE::policy` Header: `<boost/outcome/std_result.hpp>`
Project: Tetragon (Provisioning / Security & Compliance)
File: CONDUCT.md

Cobra will follow a steady release cadence. Non breaking changes will be released as minor versions quarterly. Patch bug releases are at the discretion of the maintainers. Users can expect security patch fixes to be released within relatively short order of a CVE becoming known. For more information on security patch fixes see the CVE section below. Releases will follow . Users tracking the Master branch should expect unpredictable breaking changes as the project continues to move forward. For stability, it is highly recommended to use a release. We will maintain two major releases in a moving window. The N-1 release will only receive bug fixes and security updates and will be dropped once N+1 is released. Deprecation of Go versions or dependent packages will only occur in major releases. To reduce the change of this taking users by surprise, any large deprecation will be preceded by an announcement in the and an Issue on Github. Maintainers will make every effort to release security patches in the case of a medium to high severity CVE directly impacting the library. The speed in which these patches reach a release is up to the discretion of the maintainers. A low severity CVE may be a lower priority than a high severity one. Cobra maintainers will use GitHub issues and the as the primary means of communication with the community. This is to foster open communication with all users and contributors. Breaking changes are generally allowed in the master branch, as this is the branch used to develop the next release of Cobra. There may be times, however, when master is closed for breaking changes. This is likely to happen as we near the release of a new version. Breaking changes are not allowed in release branches, as these represent minor versions that have already been released. These version have consumers who expect the APIs, behaviors, etc, to remain stable during the lifetime of the patch stream for the minor release. Examples of breaking changes include: Removing or renaming exported constant, variable, type, or function. Updating the version of critical libraries such as `spf13/pflag`, `spf13/viper` etc... Some version updates may be acceptable for picking up bug fixes, but maintainers must exercise caution when reviewing. There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the discretion of the project's maintainers, and must be carefully considered before merging. Maintainers will ensure the Cobra test suite utilizes the current supported versions of Golang. Changes to this document and the contents therein are at the discretion of the maintainers. None of the contents of this document are legally binding in any way to the maintainers or the users.
Project: SPIRE (Provisioning / Key Management)
File: plugin_agent_svidstore_aws_secretsmanager.md

The `aws_secretsmanager` plugin stores in the resulting X509-SVIDs of the entries that the agent is entitled to. The format that is used to store in a secret the issued identity is the following: ```json { "spiffeId": "spiffe://example.org", "x509Svid": "X509CERTCHAIN_PEM", "x509SvidKey": "PRIVATEKEYPEM", "bundle": "X509BUNDLEPEM", "federatedBundles": { "spiffe://federated.org": "X509FEDERATEDBUNDLE_PEM" } } ``` This plugin requires the following IAM permissions in order to function: ```text secretsmanager:DescribeSecret secretsmanager:CreateSecret secretsmanager:RestoreSecret secretsmanager:PutSecretValue secretsmanager:TagResource secretsmanager:DeleteSecret kms:Encrypt ``` Please note that this plugin does not read secrets it has stored and therefore does not require read permissions. When the SVIDs are updated, the plugin takes care of updating them in AWS Secrets Manager. | Configuration | Description | |-|-| | accesskeyid | AWS access key id. Default: value of AWSACCESSKEY_ID environment variable. | | secretaccesskey | AWS secret access key. Default: value of AWSSECRETACCESSKEY environment variable. | | region | AWS region to store the secrets. | A sample configuration: ```hcl SVIDStore "aws_secretsmanager" { plugin_data { accesskeyid = "ACCESSKEYID" secretaccesskey = "SECRETACCESSKEY" region = "us-east-1" } } ``` The selectors of the type `aws_secretsmanager` are used to describe metadata that is needed by the plugin in order to store secret values in AWS Secrets Manager. | Selector | Example | Description | ||-|-| | `awssecretsmanager:secretname` | `awssecretsmanager:secretname:some-name` | Friendly name of the secret where the SVID is stored. If not specified `aws_secretsmanager:arn` must be defined | | `awssecretsmanager:arn` | `awssecretsmanager:arn:some-arn` | The Amazon Resource Name (ARN) of the secret where the SVID is stored. If not specified, `aws_secretsmanager:secretname` must be defined | | `awssecretsmanager:kmskeyid` | `awssecretmanager:kmskeyid` | Specifies the ARN, Key ID, or alias of the AWS KMS customer master key (CMK) to be used to encrypt the secrets. Any of the supported ways to identify a AWS KMS key ID can be used. If a CMK in a different account needs to be referenced, only the key ARN or the alias ARN can be used. If not specified, the AWS account's default CMK is used |
Project: Monokle (App Definition and Development / Application Definition & Image Build)
File: how-to-configure-monokle.md

Getting started with Monokle is easy. Configure your Monokle Environment in a few minutes by following this step-by-step configuration guide. <em>Note: All settings are initialized with default values - there is no immediate need to change them. </em> Lets get started! Launch Monokle. Then. click on the Settings button to access the Settings widget: Enter the kubeconfig file path in the KUBECONFIG text field. The kubeconfig parameter is used when viewing cluster resources, deploying, and/or diffing local resources with cluster resources. Alternatively, you can click on the Browse button to fetch the kubeconfig file for configuring cluster access. To configure your cluster, select the required folder. <em>Note: The kubectl command-line tool uses kubeconfig files to find the information for choosing a cluster and communicating with the API server.</em> Monokle will look for Kubernetes manifests in files matching the chosen filter, by default this is set to .yaml/.yml files. Click on the Add Pattern button to include the files having the corresponding extension. Enter the extension pattern in the Files Include textbox. When finished, click OK. To reflect all changes, click on Apply. For deleting any extension pattern, hover over the extension, and click on the Delete icon. Then, click on Apply to ensure the change is made. To ignore specified files, folders or paths, click on the Add Pattern button and configure the pattern, files, or folders you want to exclude by including the corresponding extension. For example, node_modules. Enter the extension pattern in the Files Exclude textbox and then, click the OK button. Select Apply changes to ensure the changes have been saved and are reflected in your configuration. For deleting any extension pattern at a later time, hover over the extension, click on the delete icon, and then, click Apply to save the changes made. Click on the Helm Preview Mode dropdown to select viewing states. The options for previews are: Template - Install - Click on the Kustomize Command dropdown to select the necessary command for kustomizations. The options for the command are: Use Use Review these 6 configuration settings as needed to keep Monokle customized to your needs. Please feel free to join our open source community on Discord with this and start your discussion.
Project: SPIRE (Provisioning / Key Management)
File: using_spire.md

This page describes some options to get started with SPIRE. is an introduction to SPIRE that runs on Docker Compose Additional Docker Compose demos are available in the repo No official Helm chart, Kustomize file, or custom resource operator is available for SPIRE but includes a basic set of Kubernetes YAML files for testing SPIRE Server and Agent Additional Kubernetes demos are available in the repo The SPIRE GitHub page has download links and changelogs for each SPIRE release The spiffe.io page has additional download options and instructions for building SPIRE yourself describes how to download and test a simple one-node installation of the SPIRE Server and Agent There are no pre-built SPIRE executables available for MacOS, but describes how to download and build SPIRE to test a simple one-node installation of the SPIRE Server and Agent
Project: KICS (Provisioning / Security & Compliance)
File: ed48229d-d43e-4da7-b453-5f98d964a57a.md

title: Body Parameter Without Schema hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ed48229d-d43e-4da7-b453-5f98d964a57a Query name: Body Parameter Without Schema Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Structure and Semantics URL: The Body Parameter Object should have the attribute 'schema' defined<br> ```json title="Positive test num. 1 - json file" hl_lines="12 30" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "parameters": [ { "name": "limit2", "in": "body", "description": "max records to return", "required": true } ], "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response" } } } } }, "parameters": { "limitParam": { "name": "limit", "in": "body", "description": "max records to return", "required": true } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="20 14" swagger: "2.0" info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": description: 200 response parameters: name: limit2 in: body description: max records to return required: true parameters: limitParam: name: limit in: body description: max records to return required: true ``` ```json title="Negative test num. 1 - json file" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "parameters": [ { "name": "limit2", "in": "body", "description": "max records to return", "required": true, "schema": { "type": "integer" } } ], "operationId": "listVersionsv2", "summary": "List API versions", "responses": { "200": { "description": "200 response" } } } } }, "parameters": { "limitParam": { "name": "limit", "in": "body", "description": "max records to return", "required": true, "schema": { "type": "integer" } } } } ``` ```yaml title="Negative test num. 2 - yaml file" swagger: "2.0" info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions responses: "200": description: 200 response parameters: name: limit2 in: body description: max records to return required: true schema: type: object parameters: limitParam: name: limit in: body description: max records to return required: true schema: type: object ```
Project: The Update Framework (TUF) (Provisioning / Security & Compliance)
File: 0003-where-to-develop-TUF-1-0-0.md

Status: accepted Date: 2020-11-23 Technical Story: https://github.com/theupdateframework/python-tuf/issues/1126 The plan is to implement a refactored TUF (1.0.0) alongside the current code base, in order to not disrupt existing usage and keep providing a Python 2.7 client. We need to decide on the best place to do this development. Developing the new code piecemeal Continuing to make releases in the interim Avoiding maintenance overhead Develop TUF 1.0.0: In its own repository In a separate development branch of the current TUF implementation In the default branch, archiving the current implementation In a subdirectory of the current TUF implementation Chosen option: "Develop TUF 1.0.0 in a subdirectory of the current TUF implementation", because we want to add the new TUF code gradually while keep maintaining the current implementation given limited maintenance resources. Once development of the new version is complete, we will transition from TUF 1.0.0 in a subdirectory to stand-alone TUF 1.0.0 by the following procedure: flesh out tuf/api/ implement tuf/client/new-updater.py implement tuf/repository/ \<iterate\> git mv tuf/client/new-updater.py tuf/client/updater.py git rm tuf/\.py tag 1.0.0 Developing TUF 1.0.0 in a subdirectory of the current TUF implementation seems to have the least maintenance overhead compared to option 1 and 2, while allowing us to continue making releases with the old code unlike option 3. In progress development in the default branch causes messiness in plain sight.
Project: Apache StreamPipes (App Definition and Development / Streaming & Messaging)
File: aggregation.md

<!-- ~ Licensed to the Apache Software Foundation (ASF) under one or more ~ contributor license agreements. See the NOTICE file distributed with ~ this work for additional information regarding copyright ownership. ~ The ASF licenses this file to You 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. ~ --> Performs different aggregation functions new SDK [ ]; tested [ ]
Project: StarRocks (App Definition and Development / Database)
File: bitmap_hash.md

displayed_sidebar: "English" Calculates a 32-bit hash value for any type of input and return the bitmap containing the hash value. It is mainly used for the stream load task to import non integer fields into the bitmap field of the StarRocks table. For example: ```bash cat data | curl --location-trusted -u user:passwd -T - \ -H "columns: dt,page,deviceid, deviceid=bitmaphash(deviceid)" \ http://host:8410/api/test/testDb/streamload ``` ```Haskell BITMAP BITMAP_HASH(expr) ``` ```Plain Text MySQL > select bitmapcount(bitmaphash('hello')); ++ | bitmapcount(bitmaphash('hello')) | ++ | 1 | ++ select bitmaptostring(bitmap_hash('hello')); +-+ | bitmaptostring(bitmap_hash('hello')) | +-+ | 1321743225 | +-+ ``` BITMAP_HASH,BITMAP
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: keptn_integrations_repositories.md

Keptn integrations repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path/to/packages provided can contain metadata for one or more packages. Each package version must be on a separate folder, and it's up to you to decide if you want to publish one or multiple versions of your package. The structure of a repository with multiple integrations packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml 2.0.0 README.md artifacthub-pkg.yml package2 1.0.0 README.md artifacthub-pkg.yml ``` This structure is flexible, and in some cases it can be greatly simplified. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file and the for more details. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. Once you have added your repository, you are all set up. As you add new versions of your integrations packages or even new packages to your git repository, they'll be automatically indexed and listed in Artifact Hub.
Project: TDengine (App Definition and Development / Database)
File: 12-directory.md

title: File directory structure description: This document describes the structure of the TDengine directory after installation. After TDengine is installed, the following directories or files will be created in the system by default. | directory/file | description | | - | -- | | /usr/local/taos/bin | The TDengine executable directory. The executable files are soft-linked to the /usr/bin directory. | | /usr/local/taos/driver | The TDengine dynamic link library directory. It is soft-linked to the /usr/lib directory. | | /usr/local/taos/examples | The TDengine various language application examples directory. | | /usr/local/taos/include | The header files for TDengine's external C interface. | | /etc/taos/taos.cfg | TDengine default [configuration file] | | /var/lib/taos | TDengine's default data file directory. The location can be changed via [configuration file]. | | /var/log/taos | TDengine default log file directory. The location can be changed via [configure file]. | All executable files of TDengine are in the /usr/local/taos/bin directory by default. These include. taosd: TDengine server-side executable files taos: TDengine CLI executable taosdump: data import and export tool taosBenchmark: TDengine testing tool remove.sh: script to uninstall TDengine, please execute it carefully, link to the rmtaos command in the /usr/bin directory. Will remove the TDengine installation directory `/usr/local/taos`, but will keep `/etc/taos`, `/var/lib/taos`, `/var/log/taos` taosadapter: server-side executable that provides RESTful services and accepts writing requests from a variety of other software TDinsight.sh: script to download TDinsight and install it setcore.sh_: script for setting up the system to generate core dump files for easy debugging taosd-dump-cfg.gdb: script to facilitate debugging of taosd's gdb execution. :::tip You can configure different data directories and log directories by modifying the system configuration file `taos.cfg`. :::
Project: ClickHouse (App Definition and Development / Database)
File: v22.3.14.18-lts.md

sidebar_position: 1 sidebar_label: 2022 Backported in : - Choose correct aggregation method for LowCardinality with BigInt. (). Backported in : Update cctz to the latest master, update tzdb to 2020e. (). Backported in : Update tzdata to 2022e to support the new timezone changes. Palestine transitions are now Saturdays at 02:00. Simplify three Ukraine zones into one. Jordan and Syria switch from +02/+03 with DST to year-round +03. (https://data.iana.org/time-zones/tzdb/NEWS). This closes . (). Backported in : Fix a bug with projections and the `aggregatefunctionsnullforempty` setting. This bug is very rare and appears only if you enable the `aggregatefunctionsnullforempty` setting in the server's config. This closes . (). Backported in : This closes . (). Add a warning message to release.py script, require release type (). Revert ().
Project: Beam (App Definition and Development / Streaming & Messaging)
File: hoxtonai.md

title: "Hoxton AI" icon: /images/logos/powered-by/hoxtonai.png hasLink: "https://www.hoxton.ai/home" <!-- 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. -->