cwielenb/CNCF-Dataset huggingface dataset:
Project: Paladin Cloud (Provisioning / Security & Compliance)
File: CONTRIBUTING.md

We are open to, and grateful for, any contributions made by the community. By contributing to Paladin Cloud, you agree to abide by the . Before opening an issue, please search the to make sure your issue hasn't already been reported. We use the issue tracker to keep track of bugs and improvements, its examples, and the documentation. We encourage you to open issues to discuss improvements, architecture, theory, internal implementation, etc. If a topic has been discussed before, we will ask you to join the previous discussion. We follow semantic versioning. We release patch versions for bugfixes, minor versions for new features or non-essential changes, and major versions for any breaking changes. Submit all changes directly to the master branch. We dont use separate branches for development. We do our best to keep master in good shape, with all tests passing. Code that lands in master must be compatible with the latest stable release. It may contain additional features, but no breaking changes. We should be able to release a new minor version from the tip of master at any time. Visit the to find a list of open issues that need attention. For non-trivial changes, please open an issue with a proposal for a new feature or refactoring before starting on the work. We don't want you to waste your efforts on a pull request that we won't want to accept. On the other hand, sometimes the best way to start a conversation is to send a pull request. Use your best judgement! In general, the contribution workflow looks like this: Open a new issue in the . Fork the repo. Create a new feature branch based off the `master` branch. Make sure to add/update tests. Submit a pull request, referencing any issues it addresses. Please try to keep your pull request focused in scope and avoid including unrelated commits. We follow below guidelines for pull requests and commits: We use conventional commits and pull requests. some examples of commits: `fix:` for bugfixes `feat:` for new features `docs:` for documentation `style:` for style changes `refactor(auth-api):` for code refactoring `test:` for tests `chore:` for chores `BREAKING CHANGE:` for breaking changes Use the same conventions for pull requests as well. Rebase and test the code against the primary branch to be sure it works with the latest code After you have submitted your pull request, we'll try to get back to you as soon as possible. We may suggest some changes or improvements. Thank you for contributing!
Project: Crunchy Postgres Operator (App Definition and Development / Database)
File: restore.md

<!-- Copyright 2021 - 2024 Crunchy Data Solutions, Inc. 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 `--target-action` option of `pgbackrest restore` almost translates to the PostgreSQL `recoverytargetaction` parameter but not exactly. The behavior of that parameter also depends on the PostgreSQL version and on other parameters. For PostgreSQL 9.5 through 15, The PostgreSQL documentation states that for `recoverytargetaction` "the default is `pause`," but that is only the case when `hot_standby=on`. The PostgreSQL documentation states that when `hot_standby=off` "a setting of `pause` will act the same as `shutdown`," but that cannot be configured through pgBackRest. The default value of `hot_standby` is `off` prior to PostgreSQL 10 and `on` since. | --target-action | recoverytargetaction | hotstandby=off | hotstandby=on (default) | |||--|--| | not configured | not configured | shutdown | pause | | `pause` | not configured | shutdown | pause | | not possible | `pause` | shutdown | pause | | `promote` | `promote` | promote | promote | | `shutdown` | `shutdown` | shutdown | shutdown | | --target-action | recoverytargetaction | hotstandby=off | hotstandby=on (default) | |||--|--| | not configured | not configured | promote | pause | | `pause` | not configured | promote | pause | | not possible | `pause` | shutdown | pause | | `promote` | `promote` | promote | promote | | `shutdown` | `shutdown` | shutdown | shutdown | | --target-action | recoverytargetaction | hotstandby=off (default) | hotstandby=on | ||||-| | not configured | not configured | promote | pause | | `pause` | not configured | promote | pause | | not possible | `pause` | shutdown | pause | | `promote` | `promote` | promote | promote | | `shutdown` | `shutdown` | shutdown | shutdown | | --target-action | pauseatrecoverytarget | hotstandby=off (default) | hot_standby=on | ||--||-| | not configured | not configured | promote | pause | | `pause` | not configured | promote | pause | | not possible | `true` | promote | pause | | `promote` | `false` | promote | promote | <!-- cd /pgdata export PGDATA="$(pwd)/test" pgbackrest restore --pg1-path="$PGDATA" --stanza=db (cd "$PGDATA"; postgres -c archivecommand=false -c loggingcollector=off -c port=9999) rm -rf "$PGDATA" pgbackrest restore --pg1-path="$PGDATA" --stanza=db --type=lsn --target="$LSN" (cd "$PGDATA"; postgres -c archivecommand=false -c loggingcollector=off -c port=9999 -c hot_standby=on) grep recoverytargetaction "$PGDATA"/*.conf -->
Project: Puppet (Provisioning / Automation & Configuration)
File: README_UTIL.md

Development Utilities ===================== The scripts in this directory are utility scripts useful during development. binarysearchspecs.rb This script, written by Nick Lewis, is useful if you encounter a spec failure which only occurs when run in some sequence with other specs. If you have a spec which passes by itself, but fails when run with the full spec suite, this script will help track it down. The puppet spec/spechelper.rb checks for an environment variable LOGSPECORDER. If this is present, it will save the current order of the spec files to './specorder.txt'. This file is then used by binarysearchspecs.rb so that: $ ./util/binarysearchspecs.rb spec/unit/foo_spec.rb will begin bisecting runs before and after this spec until it narrows down to a candidate which seems to be effecting foo_spec.rb and causing it to fail. To get the groups that the parallel task is running, run: be util/rspecgrouper 1000. Then run each spit out file with "be util/rspecrunner <groupfile>". If it fails, rename it to spec_order.txt and run the binary script. For simple cases of testing REST API via curl: edit ~/tests/master/:confdir/auth.conf and add `"allow "` to `"path /"` Now you should be able to: ```bash jpartlow@percival:~/work/puppet$ curl -k -H 'Accept: text/pson' https://puppetmaster:8140/main/resource/user/nobody {"type":"User","title":"nobody","tags":["user","nobody"],"exported":false,"parameters":{"ensure":"present","home":"/nonexistent","uid":65534,"gid":65534,"comment":"nobody","shell":"/bin/sh","groups":[],"expiry":"absent","provider":"useradd","membership":"minimum","rolemembership":"minimum","authmembership":"minimum","profilemembership":"minimum","keymembership":"minimum","attribute_membership":"minimum","loglevel":"notice"}} ``` For more complex authorization cases you will need to reference the agents keys: ```bash jpartlow@percival:~/work/puppet$ curl -H 'Accept: text/pson' --cert `puppet agent --configprint hostcert` --key `be puppet agent --configprint hostprivkey` --cacert `be puppet agent --configprint localcacert` https://puppetmaster:8140/foo/node/percival.corp.puppetlabs.net ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: pip.md

+++ title = "pip resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "pip" identifier = "inspec/resources/os/pip.md pip resource" parent = "inspec/resources/os" +++ Use the `pip` Chef InSpec audit resource to test packages that are installed using the Python PIP installer. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} This resource first became available in v1.0.0 of InSpec. A `pip` resource block declares a package and (optionally) a package version: describe pip('package_name') do it { should be_installed } end where `'package_name'` is the name of the package, such as `'Jinja2'` `be_installed` tests to see if the package described above is installed The `version` property tests if the named package version is on the system: its('version') { should eq '1.2.3' } The following examples show how to use this Chef InSpec audit resource. describe pip('Jinja2') do it { should be_installed } end describe pip('Jinja2') do it { should be_installed } its('version') { should eq '2.8' } end describe pip('Jinja2', '/path/to/bin/pip') do it { should be_installed } its('version') { should eq '2.8' } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `be_installed` matcher tests if the named package is installed on the system: it { should be_installed }
Project: SPIRE (Provisioning / Key Management)
File: plugin_server_bundlepublisher_gcp_cloudstorage.md

The `gcp_cloudstorage` plugin puts the current trust bundle of the server in a designated Google Cloud Storage bucket, keeping it updated. The plugin accepts the following configuration options: | Configuration | Description | Required | Default | |-|-||-| | serviceaccountfile | Path to the service account file used to authenticate with the Cloud Storage API. | No. | Value of `GOOGLEAPPLICATIONCREDENTIALS` environment variable.| | bucket_name | The Google Cloud Storage bucket name to which the trust bundle is uploaded. | Yes. | | | object_name | The object name inside the bucket. | Yes. | | | format | Format in which the trust bundle is stored, &lt;spiffe &vert; jwks &vert; pem&gt;. See for more details. | Yes. | | The following bundle formats are supported: The trust bundle is represented as an RFC 7517 compliant JWK Set, with the specific parameters defined in the . Both the JWT authorities and the X.509 authorities are included. The trust bundle is encoded as an RFC 7517 compliant JWK Set, omitting SPIFFE-specific parameters. Both the JWT authorities and the X.509 authorities are included. The trust bundle is formatted using PEM encoding. Only the X.509 authorities are included. The plugin requires the following IAM permissions be granted to the authenticated service account in the configured bucket: ```text storage.objects.create storage.objects.delete ``` The `storage.objects.delete` permission is required to overwrite the object when the bundle is updated. The following configuration uploads the local trust bundle contents to the `example.org` object in the `spire-bundle` bucket. Since `serviceaccountfile` is not configured, are used. ```hcl BundlePublisher "gcp_cloudstorage" { plugin_data { bucket = "spire-bundle" object_name = "example.org" format = "spiffe" } } ``` The following configuration uploads the local trust bundle contents to the `example.org` object in the `spire-bundle` bucket. Since `serviceaccountfile` is configured, authentication to the Cloud Storage API is done with the given service account file. ```hcl BundlePublisher "gcp_cloudstorage" { plugin_data { serviceaccountfile = "/path/to/service/account/file" bucket = "spire-bundle" object_name = "example.org" format = "spiffe" } } ```
Project: YugabyteDB (App Definition and Development / Database)
File: unique-index-ycql.md

title: Unique indexes in YugabyteDB YCQL headerTitle: Unique indexes linkTitle: Unique indexes description: Using Unique indexes in YCQL headContent: Explore unique indexes in YugabyteDB using YCQL menu: v2.18: identifier: unique-index-ycql parent: explore-indexes-constraints weight: 231 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../unique-index-ysql/" class="nav-link"> <i class="icon-postgres" aria-hidden="true"></i> YSQL </a> </li> <li > <a href="../unique-index-ycql/" class="nav-link active"> <i class="icon-cassandra" aria-hidden="true"></i> YCQL </a> </li> </ul> If you need values in some of the columns to be unique, you can specify your index as `UNIQUE`. When a unique index is applied to two or more columns, the combined values in these columns can't be duplicated in multiple rows. Note that because a `NULL` value is treated as a distinct value, you can have multiple `NULL` values in a column with a unique index. If a table has a primary key defined, a corresponding unique index is created automatically. {{% explore-setup-single %}} ```sql CREATE UNIQUE INDEX indexname ON tablename(column_list); ``` Create a keyspace and a table as follows: ```cql ycqlsh> CREATE KEYSPACE yb_demo; ycqlsh> USE yb_demo; ycqlsh> CREATE TABLE employees(employeeno integer,name text,department text, PRIMARY KEY(employeeno)) WITH transactions = {'enabled': 'true'}; ``` Create a `UNIQUE` index for the `name` column in the `employees` table to allow only unique names in your table. ```cql CREATE UNIQUE INDEX indexemployeename ON employees(name); ``` Use the command to verify the index creation. ```cql ycqlsh:ybdemo> DESCRIBE INDEX indexemployee_name; ``` ```output CREATE UNIQUE INDEX indexemployeename ON ybdemo.employees (name) INCLUDE (employeeno) WITH transactions = {'enabled': 'true'}; ``` Insert values into the table and verify that no duplicate names are created. ```cql ycqlsh:ybdemo> INSERT INTO employees(employeeno, name, department) VALUES (1, 'John', 'Sales'); ycqlsh:ybdemo> INSERT INTO employees(employeeno, name, department) VALUES (2, 'Bob', 'Marketing'); ycqlsh:ybdemo> INSERT INTO employees(employeeno, name, department) VALUES (3, 'Bob', 'Engineering'); ``` ```output InvalidRequest: Error from server: code=2200 [Invalid query] message="Execution Error. Duplicate value disallowed by unique index indexemployeename INSERT INTO employees(employee_no, name, department) VALUES (3, 'Bob', 'Engineering'); ^^^^ (ql error -300)" ```
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: TEMPLATE.md

A short introduction to the proposal. Why we need the proposal. The goals and non-goals of the proposal. The potential solutions and comparisons. Technique details should be placed here. Risks for break changes should be highlighted. The examples of how to use if the proposal is completed. Break the proposal implementation into atomic units and estimate the time cost and difficulties for the implementation.
Project: Meshery (Provisioning / Automation & Configuration)
File: vault-operator.md

layout: integration title: Vault Operator subtitle: Collaborative and visual infrastructure as code for Vault Operator image: /assets/img/integrations/vault-operator/icons/color/vault-operator-color.svg permalink: extensibility/integrations/vault-operator docURL: https://docs.meshery.io/extensibility/integrations/vault-operator description: integrations-category: Provisioning integrations-subcategory: Key Management registrant: Artifact Hub components: name: vault colorIcon: assets/img/integrations/vault-operator/components/vault/icons/color/vault-color.svg whiteIcon: assets/img/integrations/vault-operator/components/vault/icons/white/vault-white.svg description: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: Druid (App Definition and Development / Database)
File: code-coverage.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. --> Druid code repository has an automated way of checking if new code has enough code coverage. Druid CI checks are configured to enforce code coverage using JaCoCo. The CI checks will prevent a PR from being merged if test coverage of new added code is below the set threshold. The CI checks filters test coverage based on a diff from your PR and make sure that the thresholds are met. Druid currently enforce branch and line code coverage. However, do note that our current code coverage checks are merely smoke tests. They only verify that a line or branch of code has been called during the test, but not that the functionality has been tested sufficiently. Reviewers should still verify that all the different branches are sufficiently tested by reviewing the tests. Code coverage should be run locally to make sure the PR will pass Druid CI checks. Code coverage on the codebase can be generated directly in . Code coverage on just the diff of your PR can be generated in your terminal. First, you will have to install diff-test-coverage by running `npm install @connectis/diff-test-coverage`. Next, run the unit tests for the module you are working on `mvn -pl <MODULETOCHECK> test jacoco:report` (this will create a HTML report in target/site/jacoco/index.html). Finally, run `git diff master...HEAD | diff-test-coverage --coverage "/target/site/jacoco/jacoco.xml" --type jacoco --log-template "full" --`
Project: KICS (Provisioning / Security & Compliance)
File: 4e74cf4f-ff65-4c1a-885c-67ab608206ce.md

title: Workload Host Port Not Specified hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 4e74cf4f-ff65-4c1a-885c-67ab608206ce Query name: Workload Host Port Not Specified Platform: Terraform Severity: <span style="color:#edd57e">Low</span> Category: Networking and Firewall URL: Verifies if Kubernetes workload's host port is specified<br> ```tf title="Positive test num. 1 - tf file" hl_lines="16" resource "kubernetes_pod" "test" { metadata { name = "terraform-example" } spec { container { image = "nginx:1.7.9" name = "example" env { name = "environment" value = "test" } port { container_port = 8080 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } dns_config { nameservers = ["1.1.1.1", "8.8.8.8", "9.9.9.9"] searches = ["example.com"] option { name = "ndots" value = 1 } option { name = "use-vc" } } dns_policy = "None" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="41" resource "kubernetes_deployment" "example" { metadata { name = "terraform-example" labels = { test = "MyExampleApp" } } spec { replicas = 3 selector { match_labels = { test = "MyExampleApp" } } template { metadata { labels = { test = "MyExampleApp" } } spec { container { image = "nginx:1.7.8" name = "example" resources { limits = { cpu = "0.5" memory = "512Mi" } requests = { cpu = "250m" memory = "50Mi" } } port { container_port = 8080 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } } } } } ``` ```tf title="Negative test num. 1 - tf file" resource "kubernetes_pod" "test" { metadata { name = "terraform-example" } spec { container { image = "nginx:1.7.9" name = "example" env { name = "environment" value = "test" } port { container_port = 8080 host_port = 2 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } dns_config { nameservers = ["1.1.1.1", "8.8.8.8", "9.9.9.9"] searches = ["example.com"] option { name = "ndots" value = 1 } option { name = "use-vc" } } dns_policy = "None" } } ``` ```tf title="Negative test num. 2 - tf file" resource "kubernetes_deployment" "example" { metadata { name = "terraform-example" labels = { test = "MyExampleApp" } } spec { replicas = 3 selector { match_labels = { test = "MyExampleApp" } } template { metadata { labels = { test = "MyExampleApp" } } spec { container { image = "nginx:1.7.8" name = "example" resources { limits = { cpu = "0.5" memory = "512Mi" } requests = { cpu = "250m" memory = "50Mi" } } port { container_port = 8080 host_port = 2 } liveness_probe { http_get { path = "/nginx_status" port = 80 http_header { name = "X-Custom-Header" value = "Awesome" } } initialdelayseconds = 3 period_seconds = 3 } } } } } } ```