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

slug: /en/sql-reference/aggregate-functions/reference/cramersv sidebar_position: 351 (sometimes referred to as Cramer's phi) is a measure of association between two columns in a table. The result of the `cramersV` function ranges from 0 (corresponding to no association between the variables) to 1 and can reach 1 only when each value is completely determined by the other. It may be viewed as the association between two variables as a percentage of their maximum possible variation. :::note For a bias corrected version of Cramer's V see: ::: Syntax ``` sql cramersV(column1, column2) ``` Parameters `column1`: first column to be compared. `column2`: second column to be compared. Returned value a value between 0 (corresponding to no association between the columns' values) to 1 (complete association). Type: always . Example The following two columns being compared below have no association with each other, so the result of `cramersV` is 0: Query: ``` sql SELECT cramersV(a, b) FROM ( SELECT number % 3 AS a, number % 5 AS b FROM numbers(150) ); ``` Result: ```response cramersV(a, b) 0 ``` The following two columns below have a fairly close association, so the result of `cramersV` is a high value: ```sql SELECT cramersV(a, b) FROM ( SELECT number % 10 AS a, number % 5 AS b FROM numbers(150) ); ``` Result: ```response cramersV(a, b) 0.8944271909999159 ```
Project: Chef Habitat (App Definition and Development / Application Definition & Image Build)
File: END_TO_END_TESTING.md

The are run automatically in CI with each merge to master. They are intended to run on a bare system, and thus should not be run directly on a developer workstation, as false positives, false negatives, and unintended consequences will be the result. To mimic the CI environment of the tests, the script is provided. Developers can use this to iterate locally on an individual test scenario. TEST_NAME is is the name of the test located in `test/end-to-end`, without the file extension. ```sh ./e2elocal.sh ${TESTNAME} ``` Ideally, test files will take take no arguments, but can respond to environment variables. The variables used for local testing are currently found in . Also see the for additional background. We currently don't have a good mechanism for building a set of packages off of a branch. The release pipeline can be used for this purpose, however there is always the risk of change causing an unintended release. Additionally, if you need to build against `core` origin packages that have not been promoted to stable, you won't be able to use the release pipeline. The below snippet will produce a set of packages and upload them to a named channel, allowing you to run the end-to-end tests against them locally. Substitute the builder channel containing unreleased packages for `stable` below in `HABBLDRCHANNEL` if that is required. CAUTION Do not use `stable` for `pkg upload`. This will cause an accidental release. ``` env HABBLDRCHANNEL=stable HAB_ORIGIN=core \ hab studio run "for component in hab plan-build backline studio launcher sup pkg-export-tar pkg-export-docker pkg-mesosize pkg-cfize; do build components/\$component; done" hab pkg upload --channel=YOURTESTCHANNEL results/*.hart ./e2elocal.sh TESTNAME YOURTESTCHANNEL ``` Once your tests are complete, it's a good idea to clean up your test channel ``` hab bldr channel delete YOURTESTCHANNEL ```
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: config-image-registry.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: image-dev namespace: vela-system labels: "app.oam.dev/source-of-truth": "from-inner-system" "config.oam.dev/catalog": "velacore-config" "config.oam.dev/type": "config-image-registry" project: abc spec: components: name: image-dev type: config-image-registry properties: registry: "registry.cn-beijing.aliyuncs.com" auth: username: "my-username" password: "my-password" email: "a@gmail.com" ```
Project: ClickHouse (App Definition and Development / Database)
File: v23.11.5.29-stable.md

sidebar_position: 1 sidebar_label: 2024 Backported in : Add `SYSTEM JEMALLOC PURGE` for purging unused jemalloc pages, `SYSTEM JEMALLOC (). Backported in : Allow to ignore schema evolution in Iceberg table engine and read all data using schema specified by the user on table creation or latest schema parsed from metadata on table creation. This is done under a setting `icebergengineignoreschemaevolution` that is disabled by default. Note that enabling this setting can lead to incorrect result as in case of evolved schema all data files will be read using the same schema. (). Fix a stupid case of intersecting parts (). Fix stream partitioning in parallel window functions (). Fix double destroy call on exception throw in addBatchLookupTable8 (). Fix JSONExtract function for LowCardinality(Nullable) columns (). Fix: LIMIT BY and LIMIT in distributed query (). Fix not-ready set for system.tables (). Fix translate() with FixedString input (). refine error message (). Fix rare race in external sort/aggregation with temporary data in cache (). Follow-up to (). Fix possible race in ManyAggregatedData dtor. (). Decrease log level for one log message ().
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: collect-service-endpoints.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: app-collect-service-endpoint-and-export spec: components: type: webservice name: busybox properties: image: busybox imagePullPolicy: IfNotPresent cmd: sleep '1000000' traits: type: expose properties: port: [8080] type: ClusterIP policies: type: topology name: local properties: clusters: ["local"] type: topology name: all properties: clusters: ["local", "cluster-worker"] workflow: steps: type: deploy name: deploy properties: policies: ["local"] type: collect-service-endpoints name: collect-service-endpoints outputs: name: host valueFrom: value.endpoint.host type: export-data name: export-data properties: topology: all inputs: from: host parameterKey: data.host ```
Project: Nocalhost (App Definition and Development / Application Definition & Image Build)
File: support.md

name: Support Request about: Support request or question relating to nocalhost title: '' labels: help wanted assignees: '' <!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, please add friends with WeChat ID: LiviA_ACG, You can communicate directly with the nocalhost developer. -->
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-system-context-view.md

layout: default title: mesheryctl-system-context-view permalink: reference/mesheryctl/system/context/view redirect_from: reference/mesheryctl/system/context/view/ type: reference display-title: "false" language: en command: system subcommand: context view current context Display active Meshery context <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system context view [context-name | --context context-name| --all] --flags [flags] </div> </pre> View default context <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system context view </div> </pre> View specified context <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system context view context-name </div> </pre> View specified context with context flag <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system context view --context context-name </div> </pre> View config of all contexts <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl system context view --all </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --all Show configs for all of the context -c, --context string Show config for the context -h, --help help for view </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -v, --verbose verbose output -y, --yes (optional) assume yes for user interactive prompts. </div> </pre> Usage of mesheryctl context view Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: YDB (App Definition and Development / Database)
File: bitops.md

`TestBit()`, `ClearBit()`, `SetBit()` and `FlipBit()`: Test, clear, set, or flip a bit in an unsigned number using the specified bit sequence number. Arguments: An unsigned number that's subject to the operation. TestBit is also implemented for strings. Number of the bit. TestBit returns `true/false`. The other functions return a copy of their first argument with the corresponding conversion. Examples: ```yql SELECT TestBit(1u, 0), -- true SetBit(8u, 0); -- 9 ```
Project: StarRocks (App Definition and Development / Database)
File: nullif.md

displayed_sidebar: "English" Returns NULL if `expr1` is equal to `expr2`. Otherwise, returns `expr1`. ```Haskell nullif(expr1,expr2); ``` `expr1` and `expr2` must be compatible in data type. The return value has the same type as `expr1`. ```Plain Text mysql> select nullif(1,2); +--+ | nullif(1, 2) | +--+ | 1 | +--+ mysql> select nullif(1,1); +--+ | nullif(1, 1) | +--+ | NULL | +--+ ```
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-exp-components-list.md

layout: default title: mesheryctl-exp-components-list permalink: reference/mesheryctl/exp/components/list redirect_from: reference/mesheryctl/exp/components/list/ type: reference display-title: "false" language: en command: exp subcommand: components List registered components List all components registered in Meshery Server <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp components list [flags] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> // View list of components </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp components list </div> </pre> View list of components with specified page number (25 components per page) <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp components list --page 2 </div> </pre> View Total number of components <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp components list --count </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -c, --count (optional) Get the number of components in total -h, --help help for list -p, --page int (optional) List next set of models with --page (default = 1) (default 1) </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> --config string path to config file (default "/home/runner/.meshery/config.yaml") -v, --verbose verbose output </div> </pre> Go back to , if you want to add content manually to the CLI documentation, please refer to the for guidance.
Project: Shifu (Provisioning / Automation & Configuration)
File: CHANGELOG-v0.26.0.md

Added design for telemetry service sql by @BtXin in https://github.com/Edgenesis/shifu/pull/669 Add telemetry server sql pipeline test by @Yunxe in https://github.com/Edgenesis/shifu/pull/678 @Kidr1cE made their first contribution in https://github.com/Edgenesis/shifu/pull/687 Rebase v0.25.0 by @leepala in https://github.com/Edgenesis/shifu/pull/684 Fix pull request#686 by @Kidr1cE in https://github.com/Edgenesis/shifu/pull/688 Bump sigs.k8s.io/controller-runtime from 0.15.0 to 0.15.1 by @dependabot in https://github.com/Edgenesis/shifu/pull/672 Fix Pull request#625 by @Kidr1cE in https://github.com/Edgenesis/shifu/pull/687 Bump golang.org/x/net from 0.12.0 to 0.14.0 by @dependabot in https://github.com/Edgenesis/shifu/pull/668 Bump github.com/onsi/gomega from 1.27.8 to 1.27.10 by @dependabot in https://github.com/Edgenesis/shifu/pull/664 Bump github.com/minio/minio-go/v7 from 7.0.59 to 7.0.62 by @dependabot in https://github.com/Edgenesis/shifu/pull/679 bump kind to v0.20.0, Kubernetes to v1.27.3 in demo by @Kidr1cE in https://github.com/Edgenesis/shifu/pull/689 Bump github.com/onsi/ginkgo/v2 from 2.11.0 to 2.12.0 by @dependabot in https://github.com/Edgenesis/shifu/pull/692 Bump github.com/minio/minio-go/v7 from 7.0.62 to 7.0.63 by @dependabot in https://github.com/Edgenesis/shifu/pull/693 Full Changelog: https://github.com/Edgenesis/shifu/compare/v0.25.0...v0.26.0-rc1
Project: YugabyteDB (App Definition and Development / Database)
File: dcl_create_policy.md

title: CREATE POLICY statement [YSQL] headerTitle: CREATE POLICY linkTitle: CREATE POLICY description: Use the CREATE POLICY statement to create a row level security policy for a table to select, insert, update, or delete rows that match the relevant policy expression. menu: v2.18: identifier: dclcreatepolicy parent: statements type: docs Use the `CREATE POLICY` statement to create a row level security policy for a table. A policy grants the permission to select, insert, update, or delete rows that match the relevant policy expression. Row level security must be enabled on the table using for the policies to take effect. {{%ebnf%}} create_policy {{%/ebnf%}} Where `name` is the name of the new policy. This must be distinct from any other policy name for that table. `table_name` is the name of the table that the policy applies to. `PERMISSIVE` / `RESTRICTIVE` specifies that the policy is permissive or restrictive. While applying policies to a table, permissive policies are combined together using a logical OR operator, while restrictive policies are combined using logical AND operator. Restrictive policies are used to reduce the number of records that can be accessed. Default is permissive. `role_name` is the role(s) to which the policy is applied. Default is `PUBLIC` which applies the policy to all roles. `using_expression` is a SQL conditional expression. Only rows for which the condition returns to true will be visible in a `SELECT` and available for modification in an `UPDATE` or `DELETE`. `check_expression` is a SQL conditional expression that is used only for `INSERT` and `UPDATE` queries. Only rows for which the expression evaluates to true will be allowed in an `INSERT` or `UPDATE`. Note that unlike `using_expression`, this is evaluated against the proposed new contents of the row. Create a permissive policy. ```plpgsql yugabyte=# CREATE POLICY p1 ON document USING (dlevel <= (SELECT level FROM useraccount WHERE ybuser = currentuser)); ``` Create a restricive policy. ```plpgsql yugabyte=# CREATE POLICY prestrictive ON document AS RESTRICTIVE TO userbob USING (cid <> 44); ``` Create a policy with a `CHECK` condition for inserts. ```plpgsql yugabyte=# CREATE POLICY p2 ON document FOR INSERT WITH CHECK (dauthor = current_user); ```
Project: YugabyteDB (App Definition and Development / Database)
File: copy_from,copy_to,copy_option.grammar.md

```output.ebnf copyfrom ::= COPY tablename [ ( column_name [ , ... ] ) ] FROM { 'filename' | PROGRAM 'command' | STDIN } [ [ WITH ] ( option [ , ... ] ) ] copyto ::= COPY { tablename [ ( column_names ) ] | ( query ) } TO { 'filename' | PROGRAM 'command' | STDOUT } [ [ WITH ] ( option [ , ... ] ) ] copyoption ::= FORMAT formatname | OIDS [ boolean ] | FREEZE [ boolean ] | DELIMITER 'delimiter_character' | NULL 'null_string' | HEADER [ boolean ] | QUOTE 'quote_character' | ESCAPE 'escape_character' | FORCEQUOTE { ( columnnames ) | * } | FORCENOTNULL ( column_names ) | FORCENULL ( columnnames ) | ENCODING 'encoding_name' | ROWSPERTRANSACTION integer | DISABLEFKCHECK | REPLACE | SKIP integer ```
Project: Lagoon (App Definition and Development / Application Definition & Image Build)
File: nginx.md

The . Based on the official . This Dockerfile is intended to be used as a base for any web servers within Lagoon. The default exposed port of NGINX containers is port `8080`. This image is prepared to be used on Lagoon. There are therefore some things already done: Folder permissions are automatically adapted with , so this image will work with a random user. The files within `/etc/nginx/` are parsed through with a container-entrypoint. !!! warning By default `NGINX` only serves static files - this can be used for static sites that don't require a database or PHP components: for example, static site generators like , or . If you need PHP, have a look at the `php-fpm` image and use `nginx` and `php-fpm` in tandem. Build the content during the build process and inject it into the `nginx` container. In order to create redirects, we have `redirects-map.conf` in place. This helps you to redirect marketing domains to sub-sites or do non-www to www redirects. If you have a lot of redirects, we suggest having `redirects-map.conf` stored next to your code for easier maintainability. !!! Note If you only have a few redirects, there's a handy trick to create the redirects with a `RUN` command in your `nginx.dockerfile`. Here's an example showing how to redirect `www.example.com` to `example.com` and preserve the request: ```bash title="Redirect" RUN echo "~^www.example.com http://example.com\$request_uri;" >> /etc/nginx/redirects-map.conf ``` To get more details about the various types of redirects that can be achieved, see the documentation within the directly. After you put the `redirects-map.conf` in place, you also need to include it in your `nginx.dockerfile` in order to get the configuration file into your build. ```bash title="nginx.dockerfile" COPY redirects-map.conf /etc/nginx/redirects-map.conf ``` Basic authentication is enabled automatically when the `BASICAUTHUSERNAME` and `BASICAUTHPASSWORD` [environment variables](../concepts-advanced/environment-variables.md) are set. !!! warning Automatic basic auth configuration is provided for convenience. It should not be considered a secure method of protecting your website or private data. Some options are configurable via [environment variables](../concepts-advanced/environment-variables.md). | Environment Variable | Default | Description | | :- | : | : | | BASIC_AUTH | restricted | Set to `off` to disable basic authentication. | | BASICAUTHUSERNAME | (not set) | Username for basic authentication. | | BASICAUTHPASSWORD | (not set) | Password for basic authentication (unencrypted). | | FASTHEALTHCHECK | (not set) | Set to `true` to redirect GET requests from certain user agents (StatusCake, Pingdom, Site25x7, Uptime, nagios) to the lightweight Lagoon service healthcheck. |
Project: Hazelcast IMDG (App Definition and Development / Database)
File: test-failure-report.md

name: test-failure report about: Template for test failures in testsuite title: INSERTFULLTESTNAMEHERE labels: ['Type: Test-Failure'] assignees: '' INSERTBRANCHNAMEHERE (commit INSERTCOMMITIDHERE) Failed on INSERTPLATFORMINFORMATIONHERE: INSERTLINKTOJENKINSTESTRESULT_HERE <details><summary>Stacktrace:</summary> ``` INSERTSTACKTRACEHERE ``` </details> <details><summary>Standard output:</summary> ``` INSERTINTERESTINGPARTOFSTANDARDOUTPUTHERE ``` </details>
Project: StarRocks (App Definition and Development / Database)
File: STOP_ROUTINE_LOAD.md

displayed_sidebar: "English" import RoutineLoadPrivNote from '../../../assets/commonMarkdown/RoutineLoadPrivNote.md' Stops a Routine Load job. <RoutineLoadPrivNote /> ::: warning A stopped Routine Load job cannot be resumed. Therefore, please proceed with caution when executing this statement. If you only need to pause the Routine Load job, you can execute . ::: ```SQL STOP ROUTINE LOAD FOR [dbname.]<jobname> ``` | Parameter | Required | Description | | - | | | | db_name | | The name of the database to which the Routine Load job belongs. | | job_name | | The name of the Routine Load job. | Stop the Routine Load job `exampletbl1ordertest1` in the database `example_db`. ```SQL STOP ROUTINE LOAD FOR exampledb.exampletbl1_ordertest1; ```
Project: ClickHouse (App Definition and Development / Database)
File: memory-overcommit.md

slug: /en/operations/settings/memory-overcommit Memory overcommit is an experimental technique intended to allow to set more flexible memory limits for queries. The idea of this technique is to introduce settings which can represent guaranteed amount of memory a query can use. When memory overcommit is enabled and the memory limit is reached ClickHouse will select the most overcommitted query and try to free memory by killing this query. When memory limit is reached any query will wait some time during attempt to allocate new memory. If timeout is passed and memory is freed, the query continues execution. Otherwise an exception will be thrown and the query is killed. Selection of query to stop or kill is performed by either global or user overcommit trackers depending on what memory limit is reached. If overcommit tracker can't choose query to stop, MEMORYLIMITEXCEEDED exception is thrown. User overcommit tracker finds a query with the biggest overcommit ratio in the user's query list. Overcommit ratio for a query is computed as number of allocated bytes divided by value of `memoryovercommitratio_denominator` setting. If `memoryovercommitratio_denominator` for the query is equals to zero, overcommit tracker won't choose this query. Waiting timeout is set by `memoryusageovercommitmaxwait_microseconds` setting. Example ```sql SELECT number FROM numbers(1000) GROUP BY number SETTINGS memoryovercommitratiodenominator=4000, memoryusageovercommitmaxwaitmicroseconds=500 ``` Global overcommit tracker finds a query with the biggest overcommit ratio in the list of all queries. In this case overcommit ratio is computed as number of allocated bytes divided by value of `memoryovercommitratiodenominatorfor_user` setting. If `memoryovercommitratiodenominatorfor_user` for the query is equals to zero, overcommit tracker won't choose this query. Waiting timeout is set by `memoryusageovercommitmaxwait_microseconds` parameter in the configuration file.