cwielenb/CNCF-Dataset huggingface dataset:
Project: MongoDB (App Definition and Development / Database)
File: configuration.md

This document describes the continuous integration (CI) configuration for MongoDB. There are a number of Evergreen projects supporting MongoDB's CI. For more information on Evergreen-specific terminology used in this document, please refer to the section of the Evergreen wiki. The main project for testing MongoDB's dev environments with a number build variants, each one corresponding to a particular compile or testing environment to support development. Each build variant runs a set of tasks; each task ususally runs one or more tests. Tracks the same branch as `mongodb-mongo-master`, each build variant corresponds to a (version, OS, architecure) triplet for a supported MongoDB nightly release. The system performance project. The above Evergreen projects are defined in the following files: `etc/evergreenymlcomponents/.yml`. YAML files containing definitions for tasks, functions, buildvariants, etc. They are copied from the existing evergreen.yml file. `etc/evergreen.yml`. Imports components from above and serves as the project config for mongodb-mongo-master, containing all build variants for development, including all feature-specific, patch build required, and suggested variants. `etc/evergreen_nightly.yml`. The project configuration for mongodb-mongo-master-nightly, containing only build variants for public nightly builds, imports similar components as evergreen.yml to ensure consistency. `etc/sys_perf.yml`. Configuration file for the system performance project. Only the `mongodb-mongo-master-nightly` project will be branched with required and other necessary variants (e.g. sanitizers) added back in. Most variants in `mongodb-mongo-master` would be dropped by default but can be re-introduced to the release branches manually on an as-needed basis. For Rapid releases, all but the variants relevant to Atlas in `mongodb-mongo-master-nightly` may be dropped as well.
Project: Grafeas (Provisioning / Security & Compliance)
File: feature_request.md

name: Feature request about: Suggest an idea for this project Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: YugabyteDB (App Definition and Development / Database)
File: configure.md

Configuration =============================================================================== The extension has currently a few options that be defined for the entire instance ( inside `postgresql.conf` or with `ALTER SYSTEM`). It is also possible and often a good idea to define them at the database level like this: ```sql ALTER DATABASE customers SET anon.restricttotrusted_schemas = on; ``` Only superuser can change the parameters below : anon.algorithm -- | | | ||-| | Type | Text | | Default value | 'sha256' | | Visible | only to superusers | This is the hashing method used by pseudonymizing functions. Checkout the [pgcrypto documentation] for the list of available options. See `anon.salt` to learn why this parameter is a very sensitive information. anon.maskschema -- | | | ||-| | Type | Text | | Default value | 'mask' | | Visible | to all users | The schema (i.e. 'namespace') where the dynamic masking views will be stored. anon.restricttotrusted_schemas -- | | | ||-| | Type | Boolean | | Default value | off | | Visible | to all users | By enabling this parameter, masking rules must be defined using functions located in a limited list of namespaces. By default, only the `anon` schema is trusted. This improves security by preventing users from declaring their custom masking filters. This also means that the schema must be explicit inside the masking rules. For more details, check out the [Write your own masks] section of the [Masking functions] chapter. anon.salt -- | | | ||-| | Type | Text | | Default value | (empty) | | Visible | only to superusers | This is the salt used by pseudonymizing functions. It is very important to define a custom salt for each database like this: ```sql ALTER DATABASE foo SET anon.salt = 'ThisIsAVerySecret_Salt'; ``` If a masked user can read the salt, he/she can run a brute force attack to retrieve the original data based on the 3 elements: The pseudonymized data The hashing algorithm (see `anon.algorithm`) The salt The GDPR considered that the salt and the name of the hashing algorithm should be protected with the same level of security that the data itself. This is why you should store the salt directly within the database with `ALTER DATABASE`. anon.sourceshema -- | | | ||-| | Type | Text | | Default value | 'public' | | Visible | to all users | The schema (i.e. 'namespace') where the tables are masked by the dynamic masking engine. Change this value before starting dynamic masking. ```sql ALTER DATABASE foo SET anon.sourceschema TO 'my_app'; ``` Then reconnect so that the change takes effect and start the engine. ```sql SELECT startdynamicmasking(); ```
Project: Apache Hadoop (App Definition and Development / Database)
File: RELEASENOTES.2.10.2.md

<! --> These release notes cover new developer and user-facing incompatibilities, important issues, features, and major improvements. | Minor | DFSClient#mkdirs and DFSClient#primitiveMkdir should use default directory permission* If the caller does not supply a permission, DFSClient#mkdirs and DFSClient#primitiveMkdir will create a new directory with the default directory permission 00777 now, instead of 00666. | Major | hdfs mover -p /path times out after 20 min* Mover could have fail after 20+ minutes if a block move was enqueued for this long, between two DataNodes due to an internal constant that was introduced for Balancer, but affected Mover as well. The internal constant can be configured with the dfs.balancer.max-iteration-time parameter after the patch, and affects only the Balancer. Default is 20 minutes. | Major | Install yarnpkg and upgrade nodejs in Dockerfile* In the Dockerfile, nodejs is upgraded to 8.17.0 and yarn 1.12.1 is installed. | Major | Update Dockerfile to use Bionic* The build image has been upgraded to Bionic. | Major | Intermittent S3AInputStream failures: Premature end of Content-Length delimited message body etc* WARNING: No release note provided for this change. | Major | Migrate to Python 3 and upgrade Yetus to 0.13.0* <!-- markdown --> Upgraded Yetus to 0.13.0. Removed determine-flaky-tests-hadoop.py. Temporarily disabled shelldocs check in the Jenkins jobs due to YETUS-1099. | Major | Use spotbugs-maven-plugin instead of findbugs-maven-plugin* Removed findbugs from the hadoop build images and added spotbugs instead. Upgraded SpotBugs to 4.2.2 and spotbugs-maven-plugin to 4.2.0. | Critical | Improve RM system metrics publisher's performance by pushing events to timeline server in batch* When Timeline Service V1 or V1.5 is used, if "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.enable-batch" is set to true, ResourceManager sends timeline events in batch. The default value is false. If this functionality is enabled, the maximum number that events published in batch is configured by "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.batch-size". The default value is 1000. The interval of publishing events can be configured by "yarn.resourcemanager.system-metrics-publisher.timeline-server-v1.interval-seconds". By default, it is set to 60 seconds. | Major | Replace log4j 1.x with reload4j* log4j 1 was replaced with reload4j which is fork of log4j 1.2.17 with the goal of fixing pressing security issues. If you are depending on the hadoop artifacts in your build were explicitly excluding log4 artifacts, and now want to exclude the reload4j files, you will need to update your exclusion lists \<exclusion\> \<groupId\>org.slf4j\</groupId\> \<artifactId\>slf4j-reload4j\</artifactId\> \</exclusion\> \<exclusion\> \<groupId\>ch.qos.reload4j\</groupId\> \<artifactId\>reload4j\</artifactId\> \</exclusion\>
Project: Curiefense (Provisioning / Security & Compliance)
File: README.md

This chart installs an Istiod deployment. ```console helm repo add istio https://istio-release.storage.googleapis.com/charts helm repo update ``` See for command documentation. Before installing, ensure CRDs are installed in the cluster (from the `istio/base` chart). To install the chart with the release name `istiod`: ```console kubectl create namespace istio-system helm install istiod istio/istiod --namespace istio-system ``` To uninstall/delete the `istiod` deployment: ```console helm delete istiod --namespace istio-system ``` To view support configuration options and documentation, run: ```console helm show values istio/istiod ``` Any options can be configured like below: ```yaml meshConfig: accessLogFile: /dev/stdout ``` Control plane revisions allow deploying multiple versions of the control plane in the same cluster. This allows safe ```yaml revision: my-revision-name ```
Project: ThreatMapper (Provisioning / Security & Compliance)
File: kubernetes.md

title: Kubernetes In Kubernetes, the ThreatMapper sensors are deployed as a daemonset in the Kubernetes cluster, using a helm chart. Install and start the latest release of the deepfence sensor. Replace `x.x.x.x` with the IP address of the Management Console and `73f6f3d0-9931-4b31-8967-fd6adf475f80` with the API key. If container runtime is unknown, please follow instructions. :::info `clusterName` is the name / identifier of the cluster. It should be different for different kubernetes clusters. Example: prod-cluster-1, test-cluster. ::: :::info Image tag `deepfenceio/deepfenceagentce:2.1.1-multiarch` is supported in amd64 and arm64/v8 architectures. ::: ```bash helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper helm repo update helm install deepfence-agent deepfence/deepfence-agent \ --set managementConsoleUrl=x.x.x.x \ --set deepfenceKey=73f6f3d0-9931-4b31-8967-fd6adf475f80 \ --set global.imageTag=2.1.1 \ --set clusterName="prod-cluster" \ --set mountContainerRuntimeSocket.containerdSock=true \ --set mountContainerRuntimeSocket.dockerSock=false \ --set mountContainerRuntimeSocket.crioSock=false \ --set mountContainerRuntimeSocket.podmanSock=false \ --set mountContainerRuntimeSocket.containerdSockPath="/run/containerd/containerd.sock" \ --set logLevel="info" \ --namespace deepfence \ --create-namespace \ --version 2.1.1 ``` ```bash helm repo add deepfence https://deepfence-helm-charts.s3.amazonaws.com/threatmapper helm repo update helm show values deepfence/deepfence-agent --version 2.1.1 > deepfenceagentvalues.yaml vim deepfenceagentvalues.yaml helm install -f deepfenceagentvalues.yaml deepfence-agent deepfence/deepfence-agent \ --namespace deepfence \ --create-namespace \ --version 2.1.1 ``` ```bash helm delete deepfence-agent -n deepfence ``` To get container runtime in the k8s cluster, run the following command ```shell kubectl get nodes -o=custom-columns=NAME:.metadata.name,Runtime:.status.nodeInfo.containerRuntimeVersion ``` To get container runtime socket path in the k8s cluster, run the following commands and search for `--container-runtime-endpoint` or `containerd` ```shell kubectl apply -f https://deepfence-public.s3.amazonaws.com/kubernetes/deepfence-cluster-config-job.yaml kubectl wait --for=condition=complete --timeout=30s job/deepfence-cluster-config kubectl logs $(kubectl get pod -l job-name=deepfence-cluster-config -o jsonpath="{.items[0].metadata.name}") kubectl delete -f https://deepfence-public.s3.amazonaws.com/kubernetes/deepfence-cluster-config-job.yaml ```
Project: YugabyteDB (App Definition and Development / Database)
File: commit.diagram.md

<svg class="rrdiagram" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg" width="255" height="70" viewbox="0 0 255 70"><path class="connector" d="M0 22h15m69 0h30m106 0h20m-136 25q0 5 5 5h5m57 0h54q5 0 5-5m-131-25q5 0 5 5v33q0 5 5 5h116q5 0 5-5v-33q0-5 5-5m5 0h15"/><polygon points="0,29 5,22 0,15" style="fill:black;stroke-width:0"/><rect class="literal" x="15" y="5" width="69" height="25" rx="7"/><text class="text" x="25" y="22">COMMIT</text><rect class="literal" x="114" y="5" width="106" height="25" rx="7"/><text class="text" x="124" y="22">TRANSACTION</text><rect class="literal" x="114" y="35" width="57" height="25" rx="7"/><text class="text" x="124" y="52">WORK</text><polygon points="251,29 255,29 255,15 251,15" style="fill:black;stroke-width:0"/></svg>
Project: Tremor (App Definition and Development / Streaming & Messaging)
File: operatorselect.md

The `OperatorSelect` rule provides the `select` statement in streaming queries. The statement has A target expression A stream and port from which to consume events A stream and port to which synthetic events are produced An optional set of iwndow definitions An optional `where` filter An optional `having` filter An optional `group by` Unlike ANSI-ISO SQL select operations in tremor do not presume tabular or columnar data. The target expression can be any well-formed and legal value supported by tremor.
Project: Kyverno (Provisioning / Security & Compliance)
File: kyverno.md

Kubernetes Native Policy Management. Kubernetes Native Policy Management. The Kyverno CLI provides a command-line interface to work with Kyverno resources. It can be used to validate and test policy behavior to resources prior to adding them to a cluster. The Kyverno CLI comes with additional commands to help creating and manipulating various Kyverno resources. NOTE: To enable experimental commands, environment variable "KYVERNO_EXPERIMENTAL" should be set true or 1. For more information visit https://kyverno.io/docs/kyverno-cli ``` kyverno [flags] ``` ``` --adddirheader If true, adds the file directory to the header of the log messages --alsologtostderr log to standard error as well as files (no effect when -logtostderr=true) -h, --help help for kyverno --logbacktraceat traceLocation when logging hits line file:N, emit a stack trace (default :0) --log_dir string If non-empty, write log files in this directory (no effect when -logtostderr=true) --log_file string If non-empty, use this log file (no effect when -logtostderr=true) --logfilemax_size uint Defines the maximum size a log file can grow to (no effect when -logtostderr=true). Unit is megabytes. If the value is 0, the maximum file size is unlimited. (default 1800) --logtostderr log to standard error instead of files (default true) --one_output If true, only write logs to their native severity level (vs also writing to each lower severity level; no effect when -logtostderr=true) --skip_headers If true, avoid header prefixes in the log messages --skiplogheaders If true, avoid headers when opening log files (no effect when -logtostderr=true) --stderrthreshold severity logs at or above this threshold go to stderr when writing to files and stderr (no effect when -logtostderr=true or -alsologtostderr=true) (default 2) -v, --v Level number for the log level verbosity --vmodule moduleSpec comma-separated list of pattern=N settings for file-filtered logging ``` - Applies policies on resources. - Generate the autocompletion script for the specified shell - Helps with the creation of various Kyverno resources. - Generates reference documentation. - Fix inconsistencies and deprecated usage of Kyverno resources. - Provides a command-line interface to JMESPath, enhanced with Kyverno specific custom functions. - Runs tests against any json compatible payloads/policies. - Migrate one or more resources to the stored version. - Pulls/pushes images that include policie(s) from/to OCI registries. - Run tests from a local filesystem or a remote git repository. - Prints the version of Kyverno CLI.
Project: Copa (Provisioning / Security & Compliance)
File: scanner-plugins.md

title: Scanner Plugins By default, `copa` uses to scan container images for vulnerabilities. However, we understand that different organizations have different requirements and may want to use different vulnerability scanners. Starting with v0.5.0 and later, `copa` offers extensibility to support different vulnerability scanners. Plugin architecture allows users to use the vulnerability scanner of their choice to patch container images without having to modify `copa`'s core codebase. Scanner plugin binaries must be in `$PATH`, and should be prefixed with `copa-` and have executable permissions. Copa will automatically detect and use the scanner plugin if it is in `$PATH`. For example, if you have a scanner plugin binary called `copa-foo` in `$PATH`, you can run `copa` with the following command: ```bash copa patch --scanner foo --image $IMAGE ... ``` If you have built a scanner plugin and would like to add it to this list, please submit a PR to update this section with your plugin. :::note If you have any issues with a specific plugin, please open an issue in the applicable plugin's repository. ::: Grype: https://github.com/anubhav06/copa-grype Please see instructions at for a template to get started with writing a scanner plugin. :::note `alpha` versions of the API are not guarenteed to be backwards compatible. Once the API graduates to `beta` and `stable`, it will be backwards compatible. ::: Scanner plugins must implement the following interface: ```go type UpdateManifest struct { // API version of the interface (e.g. v1alpha1) APIVersion string `json:"apiVersion"` // Metadata contains information about the OS and config Metadata Metadata `json:"metadata"` // Updates is a list of UpdatePackage that contains information about the package updates Updates UpdatePackages `json:"updates"` } // UpdatePackages is a list of UpdatePackage type UpdatePackages []UpdatePackage // Metadata contains information about the OS and config type Metadata struct { OS OS `json:"os"` Config Config `json:"config"` } type OS struct { // OS Type (e.g. debian, alpine, etc.) Type string `json:"type"` // OS Version (e.g. 11.3) Version string `json:"version"` } // Config contains information about the config type Config struct { // OS Architecture (e.g. amd64, arm64) Arch string `json:"arch"` } // UpdatePackage contains information about the package update type UpdatePackage struct { // Package name Name string `json:"name"` // Installed version InstalledVersion string `json:"installedVersion"` // Fixed version FixedVersion string `json:"fixedVersion"` // Vulnerability ID VulnerabilityID string `json:"vulnerabilityID"` } ``` From the above, we can see that the plugin must return a JSON object via standard out with the following fields. For example: ```json { "apiVersion": "v1alpha1", "metadata": { "os": { "type": "debian", "version": "11.3", }, "config": { "arch": "amd64" } }, "updates": [ { "name": "libcurl4", "installedVersion": "7.74.0-1.3+deb11u1", "fixedVersion": "7.74.0-1.3+deb11u2", "vulnerabilityID": "CVE-2021-22945" } ] } ```
Project: Beam (App Definition and Development / Streaming & Messaging)
File: talend.md

title: "Talend" icon: /images/logos/powered-by/talend.png hasLink: "https://www.youtube.com/watch?v=zwtTa0MHckU&list=PL4dEBWmGSIU9OkXQU2OAXmITPLhiMSPRp&index=17" <!-- 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. -->
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: storage.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: storage-app spec: components: name: express-server type: webservice properties: image: oamdev/hello-world ports: port: 8000 traits: type: storage properties: pvc: name: test1 mountPath: /test/mount/pvc emptyDir: name: test1 mountPath: /test/mount/emptydir configMap: name: test1 mountPath: /test/mount/cm mountToEnv: envName: TEST_ENV configMapKey: key1 data: key1: value1 key2: value2 secret: name: test1 mountPath: /test/mount/secret mountToEnv: envName: TEST_SECRET secretKey: key1 data: key1: dmFsdWUx key2: dmFsdWUy ```
Project: Plural (App Definition and Development / Application Definition & Image Build)
File: CODE_OF_CONDUCT.md

Our open source community strives to: Be friendly and patient: Remember you might not be communicating in someone elses primary spoken or programming language, and others may not have your level of understanding. Be welcoming: Our communities welcome and support people of all backgrounds and identities. This includes, but is not limited to members of any race, ethnicity, culture, national origin, color, immigration status, social and economic class, educational level, sex, sexual orientation, gender identity and expression, age, size, family status, political belief, religion, and mental and physical ability. Be respectful: We are a world-wide community of professionals, and we conduct ourselves professionally. Disagreement is no excuse for poor behavior and poor manners. Disrespectful and unacceptable behavior includes, but is not limited to: Violent threats or language. Discriminatory or derogatory jokes and language. Posting sexually explicit or violent material. Posting, or threatening to post, peoples personally identifying information (doxing). Insults, especially those using discriminatory terms or slurs. Behavior that could be perceived as sexual attention. Advocating for or encouraging any of the above behaviors. Understand disagreements: Disagreements, both social and technical, are useful learning opportunities. Seek to understand the other viewpoints and resolve differences constructively. This code is not exhaustive or complete. It serves to capture our common understanding of a productive, collaborative environment. We expect the code to be followed in spirit as much as in the letter. Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.