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

displayed_sidebar: "English" `triggers` provides information about triggers. The following fields are provided in `triggers`: | Field | Description | | -- | | | TRIGGER_CATALOG | The name of the catalog to which the trigger belongs. This value is always `def`. | | TRIGGER_SCHEMA | The name of the database to which the trigger belongs. | | TRIGGER_NAME | The name of the trigger. | | EVENT_MANIPULATION | The trigger event. This is the type of operation on the associated table for which the trigger activates. The value is `INSERT` (a row was inserted), `DELETE` (a row was deleted), or `UPDATE` (a row was modified). | | EVENTOBJECTCATALOG | Every trigger is associated with exactly one table. The catalog in which this table occurs. | | EVENTOBJECTSCHEMA | Every trigger is associated with exactly one table. The database in which this table occurs. | | EVENTOBJECTTABLE | The name of the table that the trigger is associated with. | | ACTIONORDER | The ordinal position of the trigger's action within the list of triggers on the same table with the same `EVENTMANIPULATION` and `ACTION_TIMING` values. | | ACTION_CONDITION | This value is always `NULL`. | | ACTION_STATEMENT | The trigger body; that is, the statement executed when the trigger activates. This text uses UTF-8 encoding. | | ACTION_ORIENTATION | This value is always `ROW`. | | ACTION_TIMING | Whether the trigger activates before or after the triggering event. The value is `BEFORE` or `AFTER`. | | ACTIONREFERENCEOLD_TABLE | This value is always `NULL`. | | ACTIONREFERENCENEW_TABLE | This value is always `NULL`. | | ACTIONREFERENCEOLD_ROW | The old column identifiers. The value is always `OLD`. | | ACTIONREFERENCENEW_ROW | The new column identifiers. The value is always `NEW`. | | CREATED | The date and time when the trigger was created. This is a `DATETIME(2)` value (with a fractional part in hundredths of seconds) for triggers. | | SQL_MODE | The SQL mode in effect when the trigger was created, and under which the trigger executes. | | DEFINER | The user named in the `DEFINER` clause (often the user who created the trigger). | | CHARACTERSETCLIENT | | | COLLATION_CONNECTION | | | DATABASE_COLLATION | The collation of the database with which the trigger is associated. |
Project: KICS (Provisioning / Security & Compliance)
File: fa4def8c-1898-4a35-a139-7b76b1acdef0.md

title: Insecure Port Not Properly Set hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: fa4def8c-1898-4a35-a139-7b76b1acdef0 Query name: Insecure Port Not Properly Set Platform: Kubernetes Severity: <span style="color:#bb2124">High</span> Category: Networking and Firewall URL: When using kube-apiserver command, the '--insecure-port' flag should be defined and set to 0<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver", "--insecure-port=1143"] restartPolicy: OnFailure ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="11" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: [] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver","--insecure-port=0"] restartPolicy: OnFailure ``` ```yaml title="Negative test num. 2 - yaml file" apiVersion: v1 kind: Pod metadata: name: command-demo labels: purpose: demonstrate-command spec: containers: name: command-demo-container image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0 command: ["kube-apiserver"] args: ["--insecure-port=0"] restartPolicy: OnFailure ```
Project: Podman (App Definition and Development / Application Definition & Image Build)
File: health-on-failure.md

Action to take once the container transitions to an unhealthy state. The default is none. none: Take no action. kill: Kill the container. restart: Restart the container. Do not combine the `restart` action with the `--restart` flag. When running inside of a systemd unit, consider using the `kill` or `stop` action instead to make use of systemd's restart policy. stop: Stop the container.
Project: Glasskube (App Definition and Development / Application Definition & Image Build)
File: bug_report.md

name: Bug report about: Create a report to help us improve title: '' labels: bug, needs-triage assignees: '' Describe the bug A clear and concise description of what the bug is. To Reproduce Steps to reproduce the behavior: Go to '...' Click on '....' Scroll down to '....' See error Expected behavior A clear and concise description of what you expected to happen. Screenshots If applicable, add screenshots to help explain your problem. Cluster Info (please complete the following information): Type: [e.g. Kubernetes, OpenShift] Version: [e.g. 1.29] Provider: [e.g. AWS, minikube] Glasskube Info (please complete the following information): Package Operator version: [e.g. v0.0.1] CLI version: [output of `glasskube --version`] Additional context Add any other context about the problem here.
Project: Kapitan (Provisioning / Automation & Configuration)
File: introduction.md

<iframe width="560" height="315" src="https://www.youtube.com/embed/M81qU94FCLQ?si=SGlQG-gP2mmA1n9b" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe> The Inventory is a core component of Kapitan: this section aims to explain how it works and how to best take advantage of it. The Inventory is a hierarchical `YAML` based structure which you use to capture anything that you want to make available to Kapitan, so that it can be passed on to its templating engines. The first concept to learn about the Inventory is the . A target is a file, found under the substructure, that tells Kapitan what you want to compile. It will usually map to something you want to do with Kapitan. For instance, you might want to define a for each environment that you want to deploy using Kapitan. The Inventory lets you also define and reuse common configurations through YAML files that are referred to as : by listing classes into , their content gets merged together and allows you to compose complex configurations without repetitions. By combining and , the Inventory becomes the SSOT for your whole configuration, and learning how to use it will unleash the real power of Kapitan. !!! info The Kapitan Inventory is based on an open source project called and you can find the full documentation on our Github clone. However we discourage you to look directly at the reclass documentation before you learn more about Kapitan, because Kapitan uses a fork of reclass and greatly simplifies the reclass experience. !!! info Kapitan allows users to switch the inventory backend to . You can switch the backend to reclass-rs by passing `--inventory-backend=reclass-rs` on the command line. Alternatively, you can define the backend in the . See the documentation for more details. !!! note Kapitan enforces very little structure for the Inventory, so that you can adapt it to your specific needs: this might be overwhelming at the beginning: dont worry, we will explain best practice and give guidelines soon. By default, Kapitan will search for its Inventory under and . ``` inventory/ classes applications components features kapitan projects terraform targets examples kapicorp terraform ```
Project: secureCodeBox (Provisioning / Security & Compliance)
File: container-auto-discovery.md

title: "Container AutoDiscovery" sidebar_label: "Container AutoDiscovery" path: "docs/auto-discovery/container-auto-discovery" sidebar_position: 3 The Container AutoDiscovery will create a scheduled scan with the given parameters (see for config options) for each unique container image in a Kubernetes namespace. Currently it is only possible to scan public container images. It is currently disabled by default and must be enabled manually. Assume that a namespace contains two pods that run a `nginx v1.5` container. The Container AutoDiscovery will only create a single scheduled scan for the nginx containers, as both are identical. When a third pod inside the namespace is started running a `nginx v1.6` container, the Container AutoDiscovery will create an additional scheduled scan for the `nginx v1.6` container, as it is not scanned at this point in time. The Container AutoDiscovery will look at the specific version number of each container when it determines if the container should be scanned. When both `nginx v1.5` pods get deleted the corresponding scheduled scans will also be automatically deleted because the specific container image is no longer present in the namespace. The scheduled scan for the `nginx v1.6` container will not be deleted, as it is still running in the namespace. In other words: The Container AutoDiscovery will create a single scheduled scan for each unique container image (taking the specific version number into account) in a given namespace. If a pod consists of multiple containers, the above described logic will be applied to each container individually. is a container image scanner that is used by the Container AutoDiscovery. It has to be installed in the same namespace as the containers that you wish to scan. The following steps will install trivy in the `default` namespace: ```bash helm upgrade --install trivy secureCodeBox/trivy ``` The Container AutoDiscovery is enabled by default but can be disabled manually. ```bash helm upgrade --namespace securecodebox-system --install auto-discovery-kubernetes secureCodeBox/auto-discovery-kubernetes --set config.containerAutoDiscovery.enabled=false ```
Project: secureCodeBox (Provisioning / Security & Compliance)
File: new_hook.md

name: ' New Hook request' about: 'Suggest an idea for a new data processing or integration hook in this project.' labels: 'hook' <!-- Thank you for contributing to our project Before opening a new issue, please make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead. Also, please, have a look at our FAQs and existing questions before opening a new question. --> <!-- Please describe a clear and concise description of what the problem is. Use commmon user story patterns like https://en.wikipedia.org/wiki/User_story: As a <role> I can <capability>, so that <receive benefit> In order to <receive benefit> as a <role>, I can <goal/desire> As <who> <when> <where>, I <want> because <why> For example... As a secureCodeBox user i'm always frustrated when [...] --> <!-- A clear and concise description of what you want to happen. --> <!-- A clear and concise description of any alternative solutions or features you've considered. --> <!-- Add any other context or screenshots about the feature request here. --> Hint: A general guide how to implement a new SCB Hook is documented [ ] Create a new Helm Chart with the `helm create new-hook` command in the `hooks` directory (replace `new-hook` with the name of the hook) [ ] Add a basic description of your hook Helm chart in the `Chart.yaml` [ ] (optional) Add/Edit fields in `values.yaml` [ ] Implement the hook in `hook.js` and test it in `hook.test.js` for the hook [ ] Add a brief overview of the scanner and its configuration options in `.helm-docs.gotmpl`
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: v1.9.3.md

With tracing enabled, Dapr operators can choose the sampling rate using the `spec.tracing.sampling` option in the Dapr configuration. In Dapr 1.9.0-1.9.2, when a request coming to the Dapr runtime contains a `traceparent` header, the decision on whether to sample the request or not is solely based on the "sampling bit" set in the header's value. This behavior was introduced with Dapr 1.9.0 during the transition to the new tracing framework based on the OpenTelemetry (OTEL) standard. Although this behavior is compliant with the W3C specs for distributed tracing, it caused Dapr to omit sending traces to the telemetry collector (e.g. Zipkin, Azure Monitor, etc) in many instances. The issue impacts users on Dapr 1.9.0-1.9.2 who have enabled collection of traces. Based on reports from Dapr users, developers building apps with ASP.NET Core seem to be particularly impacted, as the .NET Core framework can automatically include a `traceparent` header in every request made to the Dapr sidecar which has the "sampling bit" set to `0` (disabled). Older versions of Dapr (before 1.9.0) ignored the "sampling bit" in the `traceparent` header when making decisions on whether to sample a request. That behavior changed in Dapr 1.9.0, where the decision made by the caller with the `traceparent` header determines the Dapr runtime's sampling choice too. We have patched the way Dapr makes decisions on whether to sample a request and submit the trace to the telemetry collector (e.g. Zipkin, Azure Monitor, etc). The new behavior consists of: If the `traceparent` header has the "sampling bit" set to `1` (enabled), the request is always sampled. If the "sampling bit" is `0` (disabled), Dapr decides on whether to sample the request based on its own internal policies. For example, with `spec.tracing.sampling` set to `1`, all requests are traced; instead, a value of `0` generates no trace. Numbers in-between 0 and 1 cause Dapr to sample only a fraction of requests. This behavior, while more lax, remains compliant with the W3C specs for distributed tracing.
Project: kpt (Provisioning / Automation & Configuration)
File: feature_request.md

name: Feature Request about: Suggest an idea for kpt title: "" labels: enhancement assignees: "" Please describe your problem and specific use case, providing as much context as possible. As a general rule, it is more effective to focus on describing the problem instead of asking for a specific solution. This ensures the following: We understand WHY you are asking for this. We can pattern match across multiple users with this problem. Allow design freedom for addressing the problem given various trade-offs and UX considerations.
Project: StarRocks (App Definition and Development / Database)
File: DROP_PIPE.md

displayed_sidebar: "English" Drops a pipe and the related jobs and metadata. Executing this statement on a pipe does not revoke the data that has been loaded via this pipe. This command is supported from v3.2 onwards. ```SQL DROP PIPE [IF EXISTS] [dbname.]<pipename> ``` The name of the database to which the pipe belongs. The name of the pipe. Drop the pipe named `userbehaviorreplica` in the database named `mydatabase`: ```SQL USE mydatabase; DROP PIPE userbehaviorreplica; ```
Project: Checkov (Provisioning / Security & Compliance)
File: Contribute New Azure Pipelines Policies.md

layout: default published: true title: Contribute New Azure Pipelines configuration policy nav_order: 5 In this example, we'll add support for a new Azure Pipelines configuration check to validate the usage of a version digest. Go to `checkov/azure_pipelines/checks/jobs` and add `ContainerDigest.py`: ```python from future import annotations from typing import Any from checkov.azurepipelines.checks.baseazurepipelinescheck import BaseAzurePipelinesCheck from checkov.common.models.enums import CheckResult, CheckCategories from checkov.yaml_doc.enums import BlockType class ContainerDigest(BaseAzurePipelinesCheck): def init(self) -> None: name = "Ensure container job uses a version digest" id = "CKVAZUREPIPELINES2" super().init( name=name, id=id, categories=(CheckCategories.SUPPLY_CHAIN,), supported_entities=("jobs", "stages[].jobs[]"), block_type=BlockType.ARRAY, ) def scan_conf(self, conf: dict[str, Any]) -> tuple[CheckResult, dict[str, Any]]: container = conf.get("container") if container and isinstance(container, str): if "@" in container: return CheckResult.PASSED, conf return CheckResult.FAILED, conf return CheckResult.UNKNOWN, conf check = ContainerDigest() ``` Create a new folder under `tests/azurepipelines/checks/jobs` with the name of your check `exampleContainerDigest` for adding example configuration files. Try to add at least 2 test cases, one passing and one failing. `azure-pipelines.yml`: ```yaml trigger: master resources: repositories: repository: AzureDevOps type: git endpoint: AzureDevOps name: AzureDevOps/AzureDevOps jobs: job: RunInContainer pool: vmImage: 'ubuntu-18.04' container: ubuntu@sha256:a0a45bd8c6c4acd6967396366f01f2a68f73406327285edc5b7b07cb1cf073db steps: script: printenv ``` Lastly add the test file `test_ContainerDigest.py` to scan the example files. ```python from pathlib import Path from checkov.azure_pipelines.runner import Runner from checkov.azure_pipelines.checks.job.ContainerDigest import check from checkov.runner_filter import RunnerFilter def test_examples(): testfilesdir = Path(file).parent / "example_ContainerDigest" report = Runner().run(rootfolder=str(testfilesdir), runnerfilter=RunnerFilter(checks=[check.id])) summary = report.get_summary() passing_resources = { f"{testfilesdir}/azure-pipelines.yml.stages[].jobs[].stages[].jobs[].CKVAZUREPIPELINES2[22:31]", } failing_resources = { f"{testfilesdir}/azure-pipelines.yml.jobs.jobs.CKVAZUREPIPELINES2[32:40]", f"{testfilesdir}/azure-pipelines.yml.stages[].jobs[].stages[].jobs[].CKVAZUREPIPELINES2[14:22]", } passedcheckresources = {c.resource for c in report.passed_checks} failedcheckresources = {c.resource for c in report.failed_checks} assert summary["passed"] == len(passing_resources) assert summary["failed"] == len(failing_resources) assert summary["skipped"] == 0 assert summary["parsing_errors"] == 0 assert passedcheckresources == passing_resources assert failedcheckresources == failing_resources ``` So there you have it! A new check will be scanned once your contribution is merged!
Project: ShardingSphere (App Definition and Development / Database)
File: algorithm.en.md

+++ title = "Algorithm" weight = 4 +++ ```yaml shardingAlgorithms: <algorithmName>: type: xxx props: xxx: xxx ``` ```yaml encryptors: <encryptorName>: type: xxx props: xxx: xxx ``` ```yaml loadBalancers: type: xxx props: xxx: xxx ``` ```yaml shadowAlgorithms: <shadowAlgorithmName>: type: xxx props: xxx: xxx ``` ```yaml discoveryTypes: type: xxx props: xxx: xxx ``` ```yaml maskAlgorithms: <maskAlgorithmName>: type: xxx props: xxx: xxx ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: RELEASE.md

The `yaml` Project is released on an as-needed basis. The process is as follows: An issue is proposing a new release with a changelog since the last release All must LGTM this release An OWNER runs `git tag -s $VERSION` and inserts the changelog and pushes the tag with `git push $VERSION` The release issue is closed An announcement email is sent to `kubernetes-dev@googlegroups.com` with the subject `[ANNOUNCE] kubernetes-template-project $VERSION is released`
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_dataproc_clusters.md

+++ title = "googledataprocclusters resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googledataprocclusters" identifier = "inspec/resources/gcp/googledataprocclusters.md googledataprocclusters resource" parent = "inspec/resources/gcp" +++ A `googledataprocclusters` is used to test a Google Cluster resource This resource has beta fields available. To retrieve these fields, include `beta: true` in the constructor for the resource ```ruby describe googledataprocclusters(project: 'chef-gcp-inspec', region: 'europe-west2') do its('count') { should be >= 1 } its('cluster_names') { should include 'inspec-dataproc-cluster' } end ``` Properties that can be accessed from the `googledataprocclusters` resource: See the resource for more information. `cluster_names` : an array of `googledataproccluster` cluster_name `labels` : an array of `googledataproccluster` labels `configs` : an array of `googledataproccluster` config `regions` : an array of `googledataproccluster` region This resource supports all of the above properties as filter criteria, which can be used with `where` as a block or a method. Ensure the is enabled for the current project.
Project: Nocalhost (App Definition and Development / Application Definition & Image Build)
File: fuzzy_mode_convert_table.md

| json type \ dest type | bool | int | uint | float |string| | | | | |--|--| | number | positive => true <br/> negative => true <br/> zero => false| 23.2 => 23 <br/> -32.1 => -32| 12.1 => 12 <br/> -12.1 => 0|as normal|same as origin| | string | empty string => false <br/> string "0" => false <br/> other strings => true | "123.32" => 123 <br/> "-123.4" => -123 <br/> "123.23xxxw" => 123 <br/> "abcde12" => 0 <br/> "-32.1" => -32| 13.2 => 13 <br/> -1.1 => 0 |12.1 => 12.1 <br/> -12.3 => -12.3<br/> 12.4xxa => 12.4 <br/> +1.1e2 =>110 |same as origin| | bool | true => true <br/> false => false| true => 1 <br/> false => 0 | true => 1 <br/> false => 0 |true => 1 <br/>false => 0|true => "true" <br/> false => "false"| | object | true | 0 | 0 |0|originnal json| | array | empty array => false <br/> nonempty array => true| [] => 0 <br/> [1,2] => 1 | [] => 0 <br/> [1,2] => 1 |[] => 0<br/>[1,2] => 1|original json|
Project: Beam (App Definition and Development / Streaming & Messaging)
File: ApachePlayground.md

title: "Apache Beam Playground: An interactive environment to try transforms and examples" date: 2022-11-30 00:00:01 -0800 categories: blog aliases: /blog/2022/11/30/apache-beam-playground.html authors: alexkosolapov <!-- 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. --> is an interactive environment to try Apache Beam transforms and examples without requiring to install or set up a Beam environment. <img class="center-block" src="/images/blog/BeamPlayground.gif" alt="Apache Beam Playground"> Discover transform examples that you can try right away by browsing or searching Catalog that is sourced from Apache Beam GitHub Supports Java, Python, Go SDKs, and Scio to execute the example in Beam Direct Runner Displays pipeline execution graph (DAG) Code editor to modify examples or try your own custom pipeline with a Direct Runner Code editor with code highlighting, flexible layout, color schemes, and other features to provide responsive UX in desktop browsers Embedding a Playground example on a web page prompts the web page readers to try the example pipeline in the Playground - e.g., page Try examples in Submit your feedback using Enjoying Playground? in Apache Beam Playground or via Join the Beam mailing list Contribute to the Apache Beam Playground codebase by following a few steps in this Please if you have any feedback or encounter any issues!