cwielenb/CNCF-Dataset huggingface dataset:
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: contributing-to-storybook.md

id: contributing-to-storybook title: Contributing to Storybook description: Documentation on How to Contribute to Storybook The Backstage Storybook provides you a way to explore reusable Backstage User Interface elements and how to use them in developing the Backstage core and its plugins. These UI elements are commonly called "components", and include things such as buttons, tables, specialized widgets with specific formatting, and so on. You'll find our storybook at . As noted in the , Backstage's design is based off of . Much of the UI elements use direct Material UI, while we've also extended and written custom ones to provide specific functionality. Storybook "Stories" are used to provide examples for how to use a specific component, which are then displayed both visually and with sample code to be copied. When custom Backstage components are created, they are placed in the `@backstage/core-components` package and added to the Storybook. There may be times where an existing Material UI component (in `@material-ui/core`) is sufficient and doesn't need to be wrapped or duplicated. However, we may want to identify an opinionated way to use that component inside of Backstage. In these cases, stories showing how to use those existing components will also be put into our storybook. When a story example using Material UI becomes more complex, requiring a specific set of colors, variants, parameters, etc., it may become a candidate to be refactored to become a full Backstage core component. A Story basically represents a single visual state of a component. To create a new story, create a new file located alongside the component you want to document on Storybook. See below an example of the structure: ``` core src components Progress Progress.tsx Progress.stories.tsx ``` _Note: make sure your component story file has the following format componentName.stories.tsx_ Go to `storybook`, run `yarn install` and install the dependencies, then run the following on your command line: `yarn start` You should see a log like the image above. If everything worked out, your server will be running on port 6006, go to your browser and navigate to `http://localhost:6006/`. You should be able to navigate and see the Storybook page.
Project: SeaTunnel (App Definition and Development / Streaming & Messaging)
File: filter.md

Filter transform plugin Filter the field. | name | type | required | default value | |--|-|-|| | fields | array | yes | | The list of fields that need to be kept. Fields not in the list will be deleted Transform plugin common parameters, please refer to for details The data read from source is a table like this: | name | age | card | |-|--|| | Joy Ding | 20 | 123 | | May Ding | 20 | 123 | | Kin Dom | 20 | 123 | | Joy Dom | 20 | 123 | We want to delete field `age`, we can add `Filter` Transform like this ``` transform { Filter { sourcetablename = "fake" resulttablename = "fake1" fields = [name, card] } } ``` Then the data in result table `fake1` will like this | name | card | |-|| | Joy Ding | 123 | | May Ding | 123 | | Kin Dom | 123 | | Joy Dom | 123 | Add Filter Transform Connector
Project: Beam (App Definition and Development / Streaming & Messaging)
File: attributes.md

title: "Attributes of a Beam community member" layout: "arrow_template" <!-- 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. --> {{< figure src="/images/community/beam-logo-icon.svg" >}} They have a proven commitment to the project They share their intentions with the community They accept and integrate community feedback in their plans, designs, code, etc. They earnestly try to make Beam better with their contributions In particular, if a code contributor: They earnestly try to make Beam better with their own code They earnestly try to make Beam better with code review They accept and integrate feedback on their code They know, follow, and enforce Beams practices while reviewing/merging code - style, documentation, testing, backward compatibility, etc. {{< figure src="/images/community/messages-icon.svg" >}} In particular, we manifestly strive to: Be open Be empathetic Be welcoming Be friendly Be patient Be collaborative Be inquisitive Be careful in the words that they choose {{< figure src="/images/community/diamond-icon.svg" >}} They help create a product that will outlive the interest of any particular volunteer (including themselves) They grow and maintain the health of the Apache community They help out with surrounding work, such as the website & documentation They help users They can be trusted to decide when code is ready for release, or when to ask someone else to make the judgment They can be trusted to decide when to merge code (if a code contributor) or when to ask someone else to make the judgment
Project: RabbitMQ (App Definition and Development / Streaming & Messaging)
File: 3.9.12.md

RabbitMQ `3.9.12` is a maintenance release in the `3.9.x` release series. Please refer to the Upgrading to 3.9 section from if upgrading from a version prior to 3.9.0. This release requires at least Erlang 23.2, and supports Erlang 24. has more details on Erlang version requirements for RabbitMQ. Release notes are kept under . Contributors are encouraged to update them together with their changes. This helps with release automation and a more consistent release schedule. Work around a slow . GitHub issues: , `log.file.rotation.date` pattern parser now supports more values and is closer to Lager in RabbitMQ 3.7 and earlier releases. GitHub issue: User limits were ignored by definition import. GitHub issue: Stream coordinator could run into an exception in some scenarios. GitHub issue: On node shutdown, stopped applications were unintentionally logged at the error level. GitHub issue: `basic.` AMQP 0-9-1 operations now consume fewer CPU cycles. GitHub issue: More efficient (up to 67% more) user addition and updates, including during definition import. GitHub issue: Authentiication and authorization backend exceptions could potentially leak user-provided credentials to node log. Contributed by @luos on behalf of . GitHub issue: When a non-existent stream offset is requested, the server will return a more appropriate error code. GitHub issue: Stream operations that fail due to an unavailable leader now use a separate error code from the case when the stream does not exist. GitHub issue: Deprecated classic health check is now less resource intensive (but still very intensive compared to ). GitHub issue: Operator and regular policy merging now supports keys that use boolean values. The operator value overrides the regular policy one. GitHub issue: Free disk space monitoring robustness improvements on Windows. GitHub issue: Unnamed parameters and policies in definition files will now be rejected as invalid. Contributed by @polaris-alioth. GitHub issue: HTTPS client and related improvements for JWKS URLs. Contributed by @anhanhnguyen on behalf of . GitHub issue: None in this release. To obtain source code of the entire distribution, please download the archive named `rabbitmq-server-3.9.12.tar.xz` instead of the source tarball produced by GitHub.
Project: ClickHouse (App Definition and Development / Database)
File: approxtopsum.md

slug: /en/sql-reference/aggregate-functions/reference/approxtopsum sidebar_position: 212 Returns an array of the approximately most frequent values and their counts in the specified column. The resulting array is sorted in descending order of approximate frequency of values (not by the values themselves). Additionally, the weight of the value is taken into account. ``` sql approxtopsum(N)(column, weight) approxtopsum(N, reserved)(column, weight) ``` This function does not provide a guaranteed result. In certain situations, errors might occur and it might return frequent values that arent the most frequent values. We recommend using the `N < 10` value; performance is reduced with large `N` values. Maximum value of `N = 65536`. Parameters `N` The number of elements to return. Optional. Default value: 10. `reserved` Defines, how many cells reserved for values. If uniq(column) > reserved, result of topK function will be approximate. Optional. Default value: N * 3. Arguments `column` The value to calculate frequency. `weight` The weight. Every value is accounted `weight` times for frequency calculation. . Example Query: ``` sql SELECT approxtopsum(2)(k, w) FROM VALUES('k Char, w UInt64', ('y', 1), ('y', 1), ('x', 5), ('y', 1), ('z', 10)) ``` Result: ``` text approxtopsum(2)(k, w) [('z',10,0),('x',5,0)] ``` See Also
Project: MongoDB (App Definition and Development / Database)
File: style-guide.md

<!--* freshness: { owner: 'haberman' reviewed: '2022-05-08' } *--> Since upb is written in pure C, we supplement the with some C-specific guidance. Everything written here is intended to follow the spirit of the C++ style guide. upb is currently inconsistent about following these conventions. It is intended that all code will be updated to match these guidelines. The priority is converting public interfaces as these are more difficult to change later. C does not have namespaces. Anywhere you would normally use a namespace separator (`::`) in C++, we use an underscore (`_`) in C: ```c++ // C equivalent for upb::Arena::New() upbArena* upbArena_New(); ``` Since we rely on `_` to be our namespace separator, we never use it to merely separate words in function or type names: ```c++ // BAD: this would be interpreted as upb::FieldDef::has::default(). bool upbFieldDefhasdefault(const upbFieldDef* f); // GOOD: this is equivalent to upb::FieldDef::HasDefault(). bool upbFieldDefHasDefault(const upb_FieldDef* f); ``` For multi-word namespaces, we use `PascalCase`: ```c++ // `PyUpb` is the namespace. PyObject PyUpb_CMessage_GetAttr(PyObject _self, PyObject* attr); ``` Since we do not have `private` in C++, we use a leading underscore convention to mark internal functions and variables that should only be accessed from upb: ```c++ // Internal-only function. int64t upbInt64FromLL(); // Internal-only members. Underscore prefixes are only necessary when the // structure is defined in a header file. typedef struct { const int32t* values; // List of values <0 or >63 uint64t mask; // Bits are set for acceptable value 0 <= x < 64 int valuecount; } upb_MiniTableEnum; ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: group.md

+++ title = "group resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "group" identifier = "inspec/resources/os/group.md group resource" parent = "inspec/resources/os" +++ Use the `group` Chef InSpec audit resource to test a single group on the system. The `group` resource uses the following system groups: On non-Windows systems, the group resource tests a local group defined in the`/etc/group` file. On Windows systems, the group resource tests a local group defined by Local Users and Groups. The Chef InSpec resource distributes this resource. This resource is available from Chef Inspec 1.0.0. A `group` resource block declares a group and the details to be tested, such as if the group is a local group, the group identifier, or if the group exists. ```ruby describe group('group_name') do it { should exist } its('gid') { should eq 0 } end ``` where `group_name` must specify the group's name to be tested on the system. `exist` and `gid` are valid matchers for this resource. The `gid` property returns the named group identifier. ```ruby its('gid') { should eq 1234 } ``` The `members` property returns the members that belong to the group. ```ruby its('members') { should include 'root' } ``` where `members` returns: an array of group members for Windows Platform. For example, ["member1", "member2"] a CSV formatted string of group members for Non-Windows Platforms. For example, `"member1,member2"` The `members_array` property returns the members that belong to a group like the `members` property, however the value returned by this property is always an array of group members. ```ruby its('members_array') { should include 'root' } ``` The following examples show how to use this Chef InSpec audit resource. ```ruby describe group('root') do it { should exist } its('gid') { should eq 0 } end ``` {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}} This resource has the following special matchers. The `be_local` matcher tests if the group is a local group. ```ruby it { should be_local } ``` The `exist` matcher tests if the named group exists. ```ruby it { should exist } ``` The `have_gid` matcher tests if the named group has the given gid. ```ruby it { should have_gid 0 } ```
Project: KICS (Provisioning / Security & Compliance)
File: 7f91992f-b4c8-43bf-9bf9-fae9ecdb6e3a.md

title: File Parameter With Wrong Consumes Property hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 7f91992f-b4c8-43bf-9bf9-fae9ecdb6e3a Query name: File Parameter With Wrong Consumes Property Platform: OpenAPI Severity: <span style="color:#5bc0de">Info</span> Category: Structure and Semantics URL: Operations file parameters consumes must be 'multipart/form-data', 'application/x-www-form-urlencoded' or both<br> ```json title="Positive test num. 1 - json file" hl_lines="12" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "parameters": [ { "name": "File", "type": "file", "in": "formData" } ], "consumes": [ "application/json" ], "responses": { "200": { "description": "200 response" } } } } }, "definitions": { "User": { "type": "object", "required": [ "id", "name" ], "properties": { "id": { "type": "integer", "format": "int64" }, "name": { "type": "string" } } } } } ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="10" swagger: '2.0' info: title: Simple API Overview version: 1.0.0 paths: "/": get: operationId: listVersionsv2 summary: List API versions parameters: name: File type: file in: formData consumes: application/json responses: '200': description: 200 response definitions: User: type: object required: id name properties: id: type: integer format: int64 name: type: string ``` ```json title="Negative test num. 1 - json file" { "swagger": "2.0", "info": { "title": "Simple API Overview", "version": "1.0.0" }, "paths": { "/": { "get": { "operationId": "listVersionsv2", "summary": "List API versions", "parameters": [ { "name": "File", "type": "file", "in": "formData" } ], "consumes": [ "multipart/form-data" ], "responses": { "200": { "description": "200 response" } } } } }, "definitions": { "User": { "type": "object", "required": [ "id", "name" ], "properties": { "id": { "type": "integer", "format": "int64" }, "name": { "type": "string" } } } } } ``` ```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 parameters: name: File type: file in: formData consumes: multipart/form-data responses: '200': description: 200 response definitions: User: type: object required: id name properties: id: type: integer format: int64 name: type: string ```
Project: StarRocks (App Definition and Development / Database)
File: tables_config.md

displayed_sidebar: "English" `tables_config` provides information about the configuration of tables. The following fields are provided in `tables_config`: | Field | Description | | - | | | TABLE_SCHEMA | Name of the database that stores the table. | | TABLE_NAME | Name of the table. | | TABLE_ENGINE | Engine type of the table. | | TABLEMODEL | Data model of the table. Valid values: `DUPKEYS`, `AGGKEYS`, `UNQKEYS` or `PRI_KEYS`. | | PRIMARY_KEY | Primary key of a Primary Key table or a Unique Key table. An empty string is returned if the table is not a Primary Key table or a Unique Key table. | | PARTITION_KEY | Partitioning columns of the table. | | DISTRIBUTE_KEY | Bucketing columns of the table. | | DISTRIBUTE_TYPE | Data distribution method of the table. | | DISTRUBTE_BUCKET | Number of buckets in the table. | | SORT_KEY | Sort keys of the table. | | PROPERTIES | Properties of the table. | | TABLE_ID | ID of the table. |
Project: Okteto (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: 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. Desktop (please complete the following information): OS: [e.g. macOS] Version [e.g. 22] Additional context Add any other context about the problem here (e.g. okteto.yml, k8s manifests, logs)
Project: MongoDB (App Definition and Development / Database)
File: SCRIPTING_PROFILER_README.md

This is one time setup for a host. ```bash sudo apt install linux-tools-generic ``` Run following commands to allow `perf` runs without root permission: ```bash sudo sysctl -w kernel.perfeventparanoid=1 sudo sysctl -w kernel.kptr_restrict=0 sudo echo "kernel.perfeventparanoid=1\nkernel.kptr_restrict=0" > /etc/sysctl.d/perf.conf ``` Syntax ``` db.adminCommand( { sysprofile: 1, filename: <string>, mode: <string> } ) ``` Parameters filename: The output file of linux-perf without suffix type: `string` default value: `perf` mode: The profiling mode type: `string` possible values: `record` or `counters` default value: `record` Response ``` { pid: <integrer>, ok: 1 } ``` ``` db.adminCommand( { sysprofile: 1, pid: <integer> } ) ``` Parameters: pid: This is the perf process pid, it is returned when profiler is started. type: `integer` required: `true` ```bash let pid = db.adminCommand({sysprofile: 1, filename: "/home/ubuntu/tmp/perf_sbe"}).pid; for (let i = 0; i < 1000; ++i) { db.search.find({}).toArray(); } db.adminCommand({sysprofile: 1, pid: pid}) db.adminCommand({setParameter: 1, internalQueryFrameworkControl: "forceClassicEngine"}) pid = db.adminCommand({sysprofile: 1, filename: "/home/ubuntu/tmp/perf_classic"}).pid; for (let i = 0; i < 1000; ++i) { db.search.find({}).toArray(); } db.adminCommand({sysprofile: 1, pid: pid}) perf report -i /home/ubuntu/tmp/perf_sbe.data perf report -i /home/ubuntu/tmp/perf_classic.data ```
Project: Checkov (Provisioning / Security & Compliance)
File: ansible.md

layout: default published: true title: Ansible configuration scanning nav_order: 20 Checkov supports the evaluation of policies on your Ansible files. When using checkov to scan a directory that contains Ansible tasks it will validate if the file is compliant with Ansible best practices such as validating certificates and using HTTPS to download files, and more. Full list of Ansible policies checks can be found . ```yaml name: Verify tests hosts: all gather_facts: False tasks: name: disabled yum: name: httpd>=2.4 state: present validate_certs: false ``` ```bash checkov -d . --framework ansible ``` ```bash _| | _ | | / | '_ \ / _ \/ | |/ / _ \ \ / / | (| | | | / (| < (_) \ V / \_|_| |_|\|\|_|\_\/ \/ By Prisma Cloud | version: x.x.x ansible scan results: Passed checks: 1, Failed checks: 1, Skipped checks: 0 Check: CKVANSIBLE4: "Ensure that SSL validation isn't disabled with yum" PASSED for resource: task.disabled File: /site.yaml:6-12 Check: CKVANSIBLE3: "Ensure that certificate validation isn't disabled with yum" FAILED for resource: task.disabled File: /site.yaml:6-12 6 | - name: disabled 7 | yum: 8 | name: httpd>=2.4 9 | state: present 10 | validate_certs: false ```
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: scaffolding.md

+++ title = "Scaffolding" description = "Scaffolding" gh_repo = "habitat" [menu] [menu.habitat] title = "Scaffolding" identifier = "habitat/plans/scaffolding" parent = "habitat/plans" weight = 95 +++ Chef Habitat scaffoldings are standardized plans for automated building and running your application. Each scaffolding is tuned to the way your application was built, which allows it to create the appropriate and add in the correct runtime dependencies when building the package for your application. Scaffoldings also provide some default health check hooks where appropriate to ensure your application is functioning reliably. Customized Scaffolding can be created to facilitate re-usability of common patterns in your organization for developing, building, and running your applications. While we are targeting many platforms for automated scaffolding we currently support Ruby, Node.js and Gradle. Scaffolding provides certain customizable variables for language-specific behavior. Please see the appropriate scaffolding documentation for details. If you want to override phases of a scaffold's build in your plans, make sure to override the main `doxxx` phase, not the callback directly. ex override `doinstall()` instead of `dodefaultinstall` or `donodeinstall`. A language or framework scaffolding is shipped as a Chef Habitat package, which means that each scaffolding runtime dependency becomes a build dependency for the application being built. To create scaffolding, a package must contain a `lib/scaffolding.sh` file which gets sourced by the build program running Bash. A optional function named `scaffoldingload()` may be created in `lib/scaffolding.sh` which will be called early in the build program which allows a Scaffolding author to control and augment the `pkgdeps` and `pkgbuilddeps` arrays. At this point, no other build or run dependencies have been resolved so the code in this function can only rely on what the build program provides or software pulled in via the Scaffolding's Plan. The remainder of the `lib/scaffolding.sh` contains one or more default implementations for the build phases. These include, but are not limited to: `dodefaultprepare()` `dodefaultbuild()` `dodefaultinstall()`
Project: Chef InSpec (Provisioning / Security & Compliance)
File: google_project_logging_audit_config.md

+++ title = "googleprojectloggingauditconfig resource" draft = false gh_repo = "inspec" platform = "gcp" [menu] [menu.inspec] title = "googleprojectloggingauditconfig" identifier = "inspec/resources/gcp/googleprojectloggingauditconfig.md googleprojectloggingauditconfig resource" parent = "inspec/resources/gcp" +++ Use the `googlecomputezone` InSpec audit resource to test properties of a single GCP compute zone. A `googleprojectloggingauditconfig` resource block declares the tests for a single GCP zone by project and name. describe googleprojectloggingauditconfig(project: 'chef-inspec-gcp') do it { should exist } end The following examples show how to use this InSpec audit resource. describe googleprojectloggingauditconfig(project: 'chef-inspec-gcp') do its('defaulttypes') { should include 'ADMINREAD' } end describe googlecomputezone(project: 'chef-inspec-gcp', zone: 'us-east1-b') do it { shouldnot havedefaultexemptedmembers } end `defaulttypes`, `defaultexempted_members` Ensure the is enabled for the project.
Project: Square Keywhiz (Provisioning / Key Management)
File: CONTRIBUTING.md

If you would like to contribute code to Keywhiz you can do so through GitHub by forking the repository and sending a pull request. When submitting code, please make efforts to follow existing conventions and style in order to keep the code as readable as possible. Please also make sure your code compiles and passes tests by running `mvn clean verify`. Before your code can be accepted into the project you must also sign the Individual Contributor License Agreement. We use and you will be prompted to sign once a pull request is opened.