cwielenb/CNCF-Dataset huggingface dataset:
Project: KubeLinter (Provisioning / Security & Compliance)
File: RELEASE.md

This doc contains all steps required to release a new version of kube-linter! Decide on the version number of the next release and create a git tag for it: ```shell $ git pull --tags $ git checkout main $ git tag <new.release.version> # NOTE: PLEASE DO NOT USE THE PREFIX "v" FOR THE TAG! $ git push origin <new.release.version> ``` This will trigger a workflow that: Pushes docker images to <registry>/stackrox/kube-linter:<new.release.version>. Uploads latest built assets to the draft release. Kube-linter uses the GitHub action . This will create a draft release upon each commit on main. You should see the draft release under . Ensure you update the following: The title and flag should reflect the new release version. The compare link should reflect the new release version: `https://github.com/stackrox/kube-linter/compare/0.3.0...<new.release.version>` If you have made the required updates, review the contents once more. If everything checks out, you can publish the release! In case a wrong tag was used (i.e. prefixed with `v`, typo etc.), you could do the following: Delete the published release. Delete the existing tag. Tag the main commit with the new tag. After the workflow is run successfully, you can use the newly created draft release for publishing. For some releases, it may happen that there's an issue with the kube-linter action. Most probably, the issue will be due to the uploaded assets. In this case, you could: Remove / re-upload the assets manually, making the required changes for the release as a temporary workaround.
Project: Meshery (Provisioning / Automation & Configuration)
File: v0.6.41.md

layout: release date: 2023-01-06 tag: v0.6.41 language: en [CI] Fix image path in meshmodel docs @gr455 (#6840) Update SVG width and height in component updation @Revolyssup (#6839) [MeshModel] Define Status Types @sudo-NithishKarthik (#6831) Lowercase fields inside MeshModel metadata @Revolyssup (#6837) Migrate to MeshModel registry in pattern engine @Revolyssup (#6728) [CI] Fix build status badge in readme.md @leecalcote (#6828) Bump json5 from 1.0.1 to 1.0.2 in /provider-ui @dependabot (#6834) Bump json5 from 1.0.1 to 1.0.2 in /ui @dependabot (#6835) New configurations appear in the list after being imported @hs05june (#6818) Bump start-server-and-test from 1.14.0 to 1.15.2 in /provider-ui @dependabot (#6821) [General] Just replaced the code for deleting an application with an @partik03 (#6800) Bump postcss from 8.4.17 to 8.4.20 in /ui @dependabot (#6822) Bump golang.org/x/text from 0.4.0 to 0.5.0 @dependabot (#6824) Bump json5 from 1.0.1 to 1.0.2 in /provider-ui @dependabot (#6834) [CI] Workflow update meshery.io docs with meshmodel components @gr455 (#6838) workflow to update discussions data files added @deepakdinesh1123 (#6832) Bump json5 from 1.0.1 to 1.0.2 in /ui @dependabot (#6835) Bump start-server-and-test from 1.14.0 to 1.15.2 in /provider-ui @dependabot (#6821) Bump postcss from 8.4.17 to 8.4.20 in /ui @dependabot (#6822) Discuss tag branch @kayceeDev (#6783) [Docs/SVG] update contributing doc for svg size. @Abhishek-kumar09 (#6841) Thank you to our contributors for making this release possible: @Abhishek-kumar09, @Chadha93, @Revolyssup, @deepakdinesh1123, @dependabot, @dependabot[bot], @gr455, @hs05june, @kayceeDev, @leecalcote, @partik03 and @sudo-NithishKarthik
Project: Hazelcast IMDG (App Definition and Development / Database)
File: 013-system-time-watermarks.md

title: 013 - Resolving Sparse Events Issue with System-Time Watermarks description: Make the time progress independently from the event rate Since: 4.3 When using event time, time progresses only through the ingestion of new events. If the events are sparse, time will effectively stop until a newer event arrives. This causes high latency for time-sensitive operations such as window aggregation. In addition, Jet tracks event time for every source partition separately, and if just one partition has sparse events, time progress in the whole job is hindered. When you use `withIngestionTime()` on the pipeline, Jet won't extract the timestamp from the event, but will set it according to the local system time on the server. This way of assigning timestamps is inferior because the event isn't associated with the time at which it occurred, but at which Jet received it, causing inaccuracy in the calculations. A specifically bad problem is that, if the job restarts due to a crash, Jet must receive again some of the events it already received and processed before the crash. These events will now get different timestamps, affecting a different piece of the aggregation state. On the other hand, this timestamping approach provides the best latency: the job will never wait for delayed items, there's no need to allow any event lag as with event-time processing. We first implemented `WatermarkPolicy.limitingRealTimeLag()`. This policy emits a watermark that lags behind the system clock by a fixed amount. This policy doesn't depend on the events processed, it depends solely on the system clock. Currently, this policy is available only in Core API. Second, we made `StreamSourceStage.withIngestionTimestamps()` use this policy with zero lag. We can do this because the events are assigned with system time and we're sure that there will never be an event with an older timestamp. Further work is to allow the use of real-time watermarks in Pipeline API even for event-time processing: this will solve the sparse events issue and will give fixed latency relative to the real time, but in case the job is down for more than the real time lag, some events will be dropped as late.
Project: Apicurio Registry (App Definition and Development / Streaming & Messaging)
File: CODE_OF_CONDUCT.md

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation. Examples of behavior that contributes to creating a positive environment include: Using welcoming and inclusive language Being respectful of differing viewpoints and experiences Gracefully accepting constructive criticism Focusing on what is best for the community Showing empathy towards other community members Examples of unacceptable behavior by participants include: The use of sexualized language or imagery and unwelcome sexual attention or advances Trolling, insulting/derogatory comments, and personal or political attacks Public or private harassment Publishing others' private information, such as a physical or electronic address, without explicit permission Other conduct which could reasonably be considered inappropriate in a professional setting 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. This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership. This Code of Conduct is adapted from the , version 1.4, available at
Project: StarRocks (App Definition and Development / Database)
File: pow.md

displayed_sidebar: "English" Returns the result of `x` raised to the power of `y`. ```Haskell POW(x,y);POWER(x,y); ``` `x`: supports the DOUBLE data type. `y`: supports the DOUBLE data type. Returns a value of the DOUBLE data type. ```Plain mysql> select pow(2,2); +--+ | pow(2, 2) | +--+ | 4 | +--+ 1 row in set (0.00 sec) mysql> select power(4,3); +-+ | power(4, 3) | +-+ | 64 | +-+ 1 row in set (0.00 sec) ```
Project: KICS (Provisioning / Security & Compliance)
File: 72840c35-3876-48be-900d-f21b2f0c2ea1.md

title: EFS Not Encrypted hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 72840c35-3876-48be-900d-f21b2f0c2ea1 Query name: EFS Not Encrypted Platform: Crossplane Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Elastic File System (EFS) must be encrypted<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="8 38" apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example3 spec: forProvider: region: us-east-1 encrypted: false providerConfigRef: name: example apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: cluster-aws labels: provider: aws cluster: eks spec: compositeTypeRef: apiVersion: mydev.org/v1alpha1 kind: CompositeCluster writeConnectionSecretsToNamespace: crossplane-system patchSets: name: metadata patches: fromFieldPath: metadata.labels resources: name: sample-ec2 base: apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example4 spec: forProvider: region: us-east-1 encrypted: false providerConfigRef: name: example ``` ```yaml title="Positive test num. 2 - yaml file" hl_lines="35 6" apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example5 spec: forProvider: region: us-east-1 providerConfigRef: name: example apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: cluster-aws labels: provider: aws cluster: eks spec: compositeTypeRef: apiVersion: mydev.org/v1alpha1 kind: CompositeCluster writeConnectionSecretsToNamespace: crossplane-system patchSets: name: metadata patches: fromFieldPath: metadata.labels resources: name: sample-ec2 base: apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example6 spec: forProvider: region: us-east-1 providerConfigRef: name: example ``` ```yaml title="Negative test num. 1 - yaml file" apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example spec: forProvider: region: us-east-1 encrypted: true providerConfigRef: name: example apiVersion: apiextensions.crossplane.io/v1 kind: Composition metadata: name: cluster-aws labels: provider: aws cluster: eks spec: compositeTypeRef: apiVersion: mydev.org/v1alpha1 kind: CompositeCluster writeConnectionSecretsToNamespace: crossplane-system patchSets: name: metadata patches: fromFieldPath: metadata.labels resources: name: sample-ec2 base: apiVersion: efs.aws.crossplane.io/v1alpha1 kind: FileSystem metadata: name: example2 spec: forProvider: region: us-east-1 encrypted: true providerConfigRef: name: example ```
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: dependency-management-data.md

title: dependency-management-data subtitle: A set of tooling to get a better understanding of the use of dependencies across your organisation. labels: category: tooling layer: shell inventors: jamie-tanna blogs: https://dmd.tanna.dev/cookbooks/custom-advisories-opa/ code: https://gitlab.com/tanna.dev/dependency-management-data tutorials: https://dmd.tanna.dev/cookbooks/custom-advisories-opa/ docs_features: go-integration: note: | dependency-management-data uses the Go Rego API to make it possible to write more complex rules around usages of Open Source and internal dependencies. Example policies can be found and provide an indication of some common use-cases. dependency-management-data is a set of tooling that makes it easier to understand the usage of Open Source and internal dependencies in an organisation, taking data from Renovate, GitHub Dependabot, or Software Bill of Materials (SBOMs) and providing an SQLite database that can be used to query it. Alongside this base functionality, it's possible to write "advisories" to flag usage of certain dependencies for i.e. "this internal library has a security vulnerability" or "this Open Source project is no longer maintained". As a step further than this, it's now possible to write "policies", using Open Policy Agent to provide much more powerful control over usage of dependencies, leveraging the excellent support Rego and OPA has for common operations.
Project: secureCodeBox (Provisioning / Security & Compliance)
File: 10_quality_requirements.md

title: "Quality Requirements" sidebar_label: "Quality Requirements" sidebar_position: 10 Below, qualities are described that this project strives for. The qualities are categorized using the standard. | Category | Quality | Description | Scenario | ||-|-|--| | Functional Suitability | | | | | Performance Efficiency | Resource Efficient | SCB should scale to the available resources | SC3 | | | Time Efficient | Tasks should run parallel to optimize the use of resources | | | Compatibility | | | | | Usability | Ease of Integration | The definition and implementation of a scan process should be easy | SC4 | | Reliability | | | | | Security | | | | | Maintainability | Modular | All components should be loosely coupled to easily swap them | | | | Ease of integration | It should be possible to easily integrate new scanners | | | | Ease of Contributing | SCB should be well documented | | | | Ease of updating | Third-party software should be carefully chosen, for maintainability | SC1 | | Portability | Adaptable | SCB Should run everywhere (local, VMs, Cloud, etc.) | SC2 | | Id | Scenario | |--|-| | SC1 | A third-party updates their software with a breaking change. Effort to support this update is minimal | | SC2 | A company is running SCB in the cloud, due to limited resources on premise | | SC3 | SCB is out of resources and a new scan is initiated. The scan is queued until resources are available | | SC4 | A scan is easily created and started by writing and loading a config file |
Project: Apache Spark (App Definition and Development / Streaming & Messaging)
File: sql-ref-syntax-aux-cache-refresh-function.md

layout: global title: REFRESH FUNCTION displayTitle: REFRESH FUNCTION license: | 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. `REFRESH FUNCTION` statement invalidates the cached function entry, which includes a class name and resource location of the given function. The invalidated cache is populated right away. Note that `REFRESH FUNCTION` only works for permanent functions. Refreshing native functions or temporary functions will cause an exception. ```sql REFRESH FUNCTION function_identifier ``` function_identifier* Specifies a function name, which is either a qualified or unqualified name. If no database identifier is provided, uses the current database. Syntax: `[ databasename. ] functionname` ```sql -- The cached entry of the function will be refreshed -- The function is resolved from the current database as the function name is unqualified. REFRESH FUNCTION func1; -- The cached entry of the function will be refreshed -- The function is resolved from tempDB database as the function name is qualified. REFRESH FUNCTION db1.func1; ```
Project: ShardingSphere (App Definition and Development / Database)
File: export-database-configuration.en.md

+++ title = "EXPORT DATABASE CONFIGURATION" weight = 13 +++ The `EXPORT DATABASE CONFIGURATION` syntax is used to export storage units and rule configurations to `YAML` format. {{< tabs >}} {{% tab name="Grammar" %}} ```sql ExportDatabaseConfiguration ::= 'EXPORT' 'DATABASE' 'CONFIGURATION' ('FROM' databaseName)? ('TO' 'FILE' filePath)? databaseName ::= identifier filePath ::= string ``` {{% /tab %}} {{% tab name="Railroad diagram" %}} <iframe frameborder="0" name="diagram" id="diagram" width="100%" height="100%"></iframe> {{% /tab %}} {{< /tabs >}} When `databaseName` is not specified, the currently used logical database will be exported; if no database is used, `No database selected` will be prompted; When `filePath` is not specified, the exported information will be output through the result set; When `filePath` is specified, the file will be automatically created. If the file already exists, it will be overwritten. Export currently used logical database ```sql mysql> EXPORT DATABASE CONFIGURATION; +--+ | result | +--+ | databaseName: sharding_db dataSources: ds_1: password: 123456 url: jdbc:mysql://127.0.0.1:3306/db0 username: root minPoolSize: 1 connectionTimeoutMilliseconds: 30000 maxLifetimeMilliseconds: 2100000 readOnly: false idleTimeoutMilliseconds: 60000 maxPoolSize: 50 ds_2: password: 123456 url: jdbc:mysql://127.0.0.1:3306/db1 username: root minPoolSize: 1 connectionTimeoutMilliseconds: 30000 maxLifetimeMilliseconds: 2100000 readOnly: false idleTimeoutMilliseconds: 60000 maxPoolSize: 50 rules: | +--+ 1 row in set (0.01 sec) ``` Export the specified logical database and output it to file ```sql mysql> EXPORT DATABASE CONFIGURATION FROM shardingdb TO FILE '/xxx/configsharding_db.yaml'; +-+ | result | +-+ | Successfully exported to: '/xxx/configshardingdb.yaml' | +-+ 1 row in set (0.02 sec) ``` `EXPORT`, `DATABASE`, `CONFIGURATION`, `FROM`, `TO`, `FILE`
Project: LinuxKit (Provisioning / Automation & Configuration)
File: platform-gcp.md

This is a quick guide to run LinuxKit on GCP. A lot of internal development and CI has used Google Cloud so the support is very good; other platforms will have similar support soon. You have two choices for authentication with Google Cloud You can use You can use a Service Account You need the installed. Either install it from the URL or view `brew` (on a Mac): ```shell brew tap caskroom/cask brew cask install google-cloud-sdk ``` Or via source code: ```shell curl -SsL https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-151.0.0-darwin-x86_64.tar.gz tar xzvf google-cloud-sdk-151.0.0-darwin-x86_64.tar.gz ./google-cloud-sdk/install.sh ``` Then, set up some environment variables (adjust as needed) and login: ```shell export CLOUDSDKCOREPROJECT=<GCP project> export CLOUDSDKCOMPUTEZONE=europe-west1-d gcloud auth login ``` The authentication will redirect to a browser with Google login. Also authenticate local applications with ``` gcloud auth application-default login ``` You can use to create a Service Account. Make sure to download the credentials in JSON format and store them somewhere safe. When using `linuxkit build ...` to build an image, specify `-format gcp` to build an image in a format that GCP will understand. For example: ``` linuxkit build -format gcp myprefix.yml ``` This will create a local `myprefix.img.tar.gz` compressed image file. Do `linuxkit push gcp -project myproject-1234 -bucket bucketname myprefix.img.tar.gz` to upload it to the specified bucket, and create a bootable image from the stored image. Alternatively, you can set the project name and the bucket name using environment variables, `CLOUDSDKCOREPROJECT` and `CLOUDSDKIMAGEBUCKET`. See the constant values defined in for the complete list of the supported environment variables. With the image created, we can now create an instance and connect to the serial port. ``` linuxkit run gcp -project myproject-1234 myprefix ``` Google Cloud offers [Nested Virtualization](https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances) as a beta feature. `linuxkit` supports this by pushing the image with `linuxkit push gcp -nested-virt <other options>` and `linuxkit run gcp -nested-virt <other options>`. The `push` sets the appropriate license on the image while the `run` argument ensures that the CPU is at least Haswell or newer.
Project: Open Policy Agent (OPA) (Provisioning / Security & Compliance)
File: oauth-oidc.md

title: OAuth2 and OIDC Samples kind: misc weight: 1 OAuth2 and OpenID Connect are both pervasive technologies in modern identity systems. While verification of JSON web tokens issued by these systems is documented in the , the policy examples below aim to cover some other common use cases. Rather than storing endpoints and other metadata as part of policy data, the authorization server metadata endpoint may be queried for this data. ```live:oidc:module package oidc issuers := {"https://issuer1.example.com", "https://issuer2.example.com"} metadata_discovery(issuer) := http.send({ "url": concat("", [issuers[issuer], "/.well-known/openid-configuration"]), "method": "GET", "force_cache": true, "forcecacheduration_seconds": 86400 # Cache response for 24 hours }).body claims := jwt.decode(input.token)[1] metadata := metadata_discovery(claims.iss) jwksendpoint := metadata.jwksuri tokenendpoint := metadata.tokenendpoint ``` Below example uses the keys published at the JWKS endpoint of the authorization server for token verification. ```live:oidc2:module package oidc jwks_request(url) := http.send({ "url": url, "method": "GET", "force_cache": true, "forcecacheduration_seconds": 3600 # Cache response for an hour }) jwks := jwksrequest("https://authorization-server.example.com/jwks").rawbody verified := io.jwt.verify_rs256(input.token, jwks) ``` Use the keys published at the JWKS endpoint of the authorization server for token verification, with taken into account. ```live:oidc3:module package oidc jwks_request(url) := http.send({ "url": url, "method": "GET", "force_cache": true, "forcecacheduration_seconds": 3600 }) jwt_unverified := io.jwt.decode(input.token) jwtheader := jwtunverified[0] jwks_url := concat("?", [ "https://authorization-server.example.com/jwks", urlquery.encodeobject({"kid": jwtheader.kid}), ]) jwks := jwksrequest(jwksurl).raw_body jwtverified := jwtunverified { io.jwt.verify_rs256(input.token, jwks) } claimsverified := jwtverified[1] ``` Programmatically obtain an OAuth2 access token following the client credentials or resource owner password credential flow. ```live:oauth:module package oauth2 token := t { response := http.send({ "url": "https://authorization-server.example.com/token", "method": "POST", "headers": { "Content-Type": "application/x-www-form-urlencoded", "Authorization": concat(" ", [ "Basic", base64.encode(sprintf("%v:%v", [clientid, clientsecret])) ]), }, "rawbody": "granttype=client_credentials", "force_cache": true, "forcecachedurationseconds": 3595, # Given an `expiresin` value of 3600 }) response.status_code == 200 t := response.body.access_token } ```