cwielenb/CNCF-Dataset huggingface dataset:
Project: ko (App Definition and Development / Application Definition & Image Build)
File: multi-platform.md

Because Go supports cross-compilation to other CPU architectures and operating systems, `ko` excels at producing multi-platform images. To build and push an image for all platforms supported by the configured base image, simply add `--platform=all`. This will instruct `ko` to look up all the supported platforms in the base image, execute `GOOS=<os> GOARCH=<arch> GOARM=<variant> go build` for each platform, and produce a manifest list containing an image for each platform. You can also select specific platforms, for example, `--platform=linux/amd64,linux/arm64`. `ko` also has experimental support for building for Windows images. See .
Project: StarRocks (App Definition and Development / Database)
File: referential_constraints.md

displayed_sidebar: "English" `referential_constraints` contains all referential (foreign key) constraints. The following fields are provided in `referential_constraints`: | Field | Description | | - | | | CONSTRAINT_CATALOG | The name of the catalog to which the constraint belongs. This value is always `def`. | | CONSTRAINT_SCHEMA | The name of the database to which the constraint belongs. | | CONSTRAINT_NAME | The name of the constraint. | | UNIQUECONSTRAINTCATALOG | The name of the catalog containing the unique constraint that the constraint references. This value is always `def`. | | UNIQUECONSTRAINTSCHEMA | The name of the schema containing the unique constraint that the constraint references. | | UNIQUECONSTRAINTNAME | The name of the unique constraint that the constraint references. | | MATCH_OPTION | The value of the constraint `MATCH` attribute. The only valid value at this time is `NONE`. | | UPDATE_RULE | The value of the constraint `ON UPDATE` attribute. Valid values: `CASCADE`, `SET NULL`, `SET DEFAULT`, `RESTRICT`, and `NO ACTION`. | | DELETE_RULE | The value of the constraint `ON DELETE` attribute. Valid values: `CASCADE`, `SET NULL`, `SET DEFAULT`, `RESTRICT`, and `NO ACTION`. | | TABLENAME | The name of the table. This value is the same as in the `TABLECONSTRAINTS` table. | | REFERENCEDTABLENAME | The name of the table referenced by the constraint. |
Project: Dragonfly (Provisioning / Container Registry)
File: ADOPTERS.md

This list shows non-exhaustive adopters of dragonfly. If you are using to dragonfly to improve your distribution, then please add your team and use-case to this file. __ - GCP provides click to deploy Dragonfly in through , refer to . __ - Volcano Engine provides Dragonfly integration in Volcano Engine Kubernetes Engine(VKE) and Container Registry(CR), visit & to Learn more.. __ - Baidu AI Cloud provides click to P2P Acceleration in , power by Dragonfly. __ - Aliyun provides install in , refer to . Recommend to deploy the more efficient and stable , refer to . __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution. __ - Large-scale image distribution. __ - Large-scale image and file distribution. __ - Large-scale image and file distribution. __ - Large-scale image distribution.
Project: Apache Hadoop (App Definition and Development / Database)
File: CHANGELOG.0.12.2.md

<! --> | JIRA | Summary | Priority | Component | Reporter | Contributor | |:- |:- | : |:- |:- |:- | | | A block report processing may incorrectly cause the namenode to delete blocks | Major | . | dhruba borthakur | dhruba borthakur | | | XmlRecordInput class should be public | Major | record | Runping Qi | Milind Bhandarkar | | | Deadlock bug involving the o.a.h.metrics package | Major | metrics | David Bowen | David Bowen | | | Streaming -reducer and -mapper no longer have defaults | Major | . | Nigel Daley | Owen O'Malley |
Project: Chef InSpec (Provisioning / Security & Compliance)
File: mssql_sys_conf.md

+++ title = "mssqlsysconf resource" draft = false gh_repo = "inspec" platform = "os" [menu] [menu.inspec] title = "mssqlsysconf" identifier = "inspec/resources/os/mssqlsysconf.md mssqlsysconf resource" parent = "inspec/resources/os" +++ Use the `mssqlsysconf` Chef InSpec audit resource to test the configuration of a Microsoft SQL Server database. {{< readfile file="content/inspec/reusable/md/inspec_installation.md" >}} You must have database access. A `mssqlsysconf` resource block declares the configuration item, user, and password to test. ```ruby describe mssqlsysconf("CONFIGURATION ITEM TO TEST", user: 'USER', password: 'PASSWORD') do its("valueinuse") { should cmp "EXPECTED_VALUE" } its("valueconfigured") { should cmp "EXPECTEDVALUE" } end ``` where: `mssqlsysconf` declares a configuration item, `user`, and `password` with permission to use `sys.configurations`. `its('valueinuse') { should cmp 'EXPECTED_VALUE' }` compares the current running value of the configuration item against an expected value. `its('valueconfigured') { should cmp 'EXPECTEDVALUE' }` compares the saved value of the configuration item against an expected value. `mssqlsysconf` is based on the `mssqlsession` resource and accepts all the parameters that `mssqlsession` accepts. The user name. Default value: `SA`. The following examples show how to use this Chef InSpec audit resource. describe mssqlsysconf("clr_enabled", user: 'USER', password: 'PASSWORD') do its("valueinuse") { should cmp "0" } its("value_configured") { should cmp "0" } end {{< readfile file="content/inspec/reusable/md/inspecmatcherslink.md" >}}
Project: YugabyteDB (App Definition and Development / Database)
File: gorm.md

title: GORM ORM headerTitle: Use an ORM linkTitle: Use an ORM description: Go GORM support for YugabyteDB headcontent: Go ORM support for YugabyteDB menu: v2.18: identifier: go-orm parent: go-drivers weight: 600 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li > <a href="../gorm/" class="nav-link active"> <i class="icon-postgres" aria-hidden="true"></i> GORM ORM </a> </li> <li > <a href="../pg/" class="nav-link"> <i class="icon-postgres" aria-hidden="true"></i> PG ORM </a> </li> </ul> is the ORM library for Golang. Learn how to establish a connection to a YugabyteDB database and begin basic CRUD operations using the steps on the page. The following sections break down the example to demonstrate how to perform common tasks required for Go application development using GORM. Import the GORM packages by adding the following import statement in your application's `main.go` code. ```go import ( "github.com/jinzhu/gorm" _ "github.com/jinzhu/gorm/dialects/postgres" ) ``` Go applications can connect to the YugabyteDB database using the `gorm.Open()` function. ```go conn := fmt.Sprintf("host= %s port = %d user = %s password = %s dbname = %s sslmode=disable", host, port, user, password, dbname) var err error db, err = gorm.Open("postgres", conn) defer db.Close() if err != nil { panic(err) } ``` | Parameter | Description | Default | | :- | :- | : | | host | Hostname of the YugabyteDB instance | localhost | port | Listen port for YSQL | 5433 | user | User connecting to the database | yugabyte | password | Password for connecting to the database | yugabyte | dbname | Database name | yugabyte Define a struct which maps to the table schema and use `AutoMigrate()` to create the table. ```go type Employee struct { Id int64 `gorm:"primary_key"` Name string `gorm:"size:255"` Age int64 Language string `gorm:"size:255"` } ... // Create table db.Debug().AutoMigrate(&Employee{}) ``` Read more on designing . To write data to YugabyteDB, use the `db.Create()` function. ```go // Insert value db.Create(&Employee{Id: 1, Name: "John", Age: 35, Language: "Golang-GORM"}) db.Create(&Employee{Id: 2, Name: "Smith", Age: 24, Language: "Golang-GORM"}) ``` To query data from YugabyteDB tables, use the `db.Find()` function. ```go // Display input data var employees []Employee db.Find(&employees) for _, employee := range employees { fmt.Printf("Employee ID:%d\nName:%s\nAge:%d\nLanguage:%s\n", employee.Id, employee.Name, employee.Age, employee.Language) fmt.Printf("--\n") } ``` Build Go applications using
Project: Docker Compose (App Definition and Development / Application Definition & Image Build)
File: compose_push.md

<!MARKERGENSTART--> Push service images | Name | Type | Default | Description | |:-|:--|:--|:-| | `--dry-run` | | | Execute command in dry run mode | | `--ignore-push-failures` | | | Push what it can and ignores images with push failures | | `--include-deps` | | | Also push images of services declared as dependencies | | `-q`, `--quiet` | | | Push without printing progress information | <!MARKERGENEND--> Pushes images for services to their respective registry/repository. The following assumptions are made: You are pushing an image you have built locally You have access to the build key Examples ```yaml services: service1: build: . image: localhost:5000/yourimage ## goes to local registry service2: build: . image: your-dockerid/yourimage ## goes to your repository on Docker Hub ```
Project: FOSSA (Provisioning / Security & Compliance)
File: project.md

This `fossa project` subcommand allows users to interact with FOSSA projects. It has the following subcommand: See the pages linked above for more details. Edits a FOSSA project's settings and configurations. Example: ```bash fossa project edit --project-locator custom+1/example --title example-title --project-url github.com/fossas/fossa-cli --jira-project-key example-jira-key --link fossa.com --team example-team-1 --team example-team-2 --policy example-policy --project-label example-label-1 --project-label example-label-2 ``` Where can I find my project locator? The project Locator defines a unique ID that the FOSSA API will use to reference this project within FOSSA. The project locator can be found in the UI on the project `Settings` page listed as the "Project Locator" underneath the "Project Title" setting. <img src="../../assets/project-locator-example.png">
Project: external-secrets (Provisioning / Security & Compliance)
File: 006-LTS-release.md

WRT: https://github.com/external-secrets/external-secrets/issues/2044 We want to provide security patches and critical bug fixes in a timely manner to our users. To do so, we offer long-term support for our latest two (N, N-1) software releases. We aim for a 2-3 month minor release cycle, i.e. a given release is supported for about 4-6 months. We want to cover the following cases: weekly image rebuilds to update OS dependencies weekly go dependency updates backport bug fixes on demand Note: features cut off on a minor release will not be backported to older releases. We have set up a Github Action (GHA) which will automatically update the `go.mod` dependencies once per week or on request. The GHA will make the necessary code changes and opens a PR. Once approved and merged into `main` or `release-x.y` our build pipelines will build and push the artifact to ghcr. Bug Fixes will be merged onto each release branch individually. This is achieved by creating separate PRs from a corresponding branch of the release (e.g. bug fixes targetting `release-1.0` should be created from `release-1.0` branch). Once approved and merged into `main` or `release-x.y`, ou build pipeline will build and push the artifact to ghcr When a new minor release is cut and merged into `main`, we must branch off to `release-{major}.{minor}`. This is the long-lived release branch that will get dependency updates and bug fixes. In case we do a `patch` release we must also merge into the correct `release-{major}.{minor}` branch. We'll have a release issue template that gives the release lead a task list to work through all the steps needed to create a release. [ ] ask in `#external-secrets-dev` if we're ready for a release cut-off or if something needs to get urgently in is up to date [ ] version table [ ] Provider Stability and Support table [ ] Provider Feature Support table - [ ] move issues to next milestone [ ] close milestone [ ] Announce release on `#external-secrets` in Slack
Project: Dapr (App Definition and Development / Application Definition & Image Build)
File: GOVERNANCE.md

are responsible for activities around maintaining and updating Dapr. Final decisions on the project reside with the project maintainers. Maintainers MUST remain active. If they are unresponsive for >3 months, they will be automatically removed unless a of the other project maintainers agrees to extend the period to be greater than 3 months. New maintainers can be added to the project by a vote of the existing maintainers. A potential maintainer may be nominated by an existing maintainer. A vote is conducted in private between the current maintainers over the course of a one week voting period. At the end of the week, votes are counted and a pull request is made on the repo adding the new maintainer to the file. A maintainer may step down by submitting an stating their intent. Changes to this governance document require a pull request with approval from a of the current maintainers. This project has adopted the
Project: Kui (App Definition and Development / Application Definition & Image Build)
File: kui_shell_plugin_kubectl.WithRawData.md

/ / WithRawData .WithRawData | Name | Type | | :-- | :-- | | `Content` | `void` | `ResourceWithMetadata`<`Content`\> `WithRawData` `Optional` apiVersion: `string` ResourceWithMetadata.apiVersion packages/core/mdist/models/entity.d.ts:37 `Optional` content: `Content` ResourceWithMetadata.content packages/core/mdist/models/entity.d.ts:50 `Optional` contentType: `string` ResourceWithMetadata.contentType packages/core/mdist/models/entity.d.ts:51 `Optional` kind: `string` ResourceWithMetadata.kind packages/core/mdist/models/entity.d.ts:22 `Optional` kuiRawData: `string` `Optional` metadata: `Object` | Name | Type | | :- | :- | | `creationTimestamp?` | `string` | | `generation?` | `string` | | `labels?` | `Record`<`string`, `string`\> | | `name` | `string` | | `namespace?` | `string` | ResourceWithMetadata.metadata packages/core/mdist/models/entity.d.ts:23 `Optional` nameHash: `string` ResourceWithMetadata.nameHash packages/core/mdist/models/entity.d.ts:42 `Optional` onclick: `Object` family of onclick handlers | Name | Type | | :-- | :- | | `kind?` | `string` | | `name?` | `string` | | `nameHash?` | `string` | | `namespace?` | `string` | ResourceWithMetadata.onclick packages/core/mdist/models/entity.d.ts:44 `Optional` presentation: `Presentation` ResourceWithMetadata.presentation packages/core/mdist/models/entity.d.ts:53 `Optional` prettyName: `string` name hash, e.g. the hash part of auto-generated names, or an openwhisk activation id ResourceWithMetadata.prettyName packages/core/mdist/models/entity.d.ts:41 `Optional` toolbarText: `ToolbarText` ResourceWithMetadata.toolbarText packages/core/mdist/models/entity.d.ts:52 `Optional` version: `string` optional designation of resource version ResourceWithMetadata.version packages/core/mdist/models/entity.d.ts:39
Project: Apache Heron (App Definition and Development / Streaming & Messaging)
File: uploaders-local-fs.md

id: version-0.20.0-incubating-uploaders-local-fs title: Local File System sidebar_label: Local File System original_id: uploaders-local-fs <!-- 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. --> When you submit a topology to Heron, the topology jars will be uploaded to a stable location. The submitter will provide this location to the scheduler and it will pass it to the executor each container. Heron can use a local file system as a stable storage for topology jar distribution. There are a few things you should be aware of local file system uploader: Local file system uploader is mainly used in conjunction with local scheduler. It is ideal, if you want to run Heron in a single server, laptop or an edge device. Useful for Heron developers for local testing of the components. You can make Heron aware of the local file system uploader by modifying the `uploader.yaml` config file specific for the Heron cluster. You'll need to specify the following for each cluster: `heron.class.uploader` Indicate the uploader class to be loaded. You should set this to `org.apache.heron.uploader.localfs.LocalFileSystemUploader` `heron.uploader.localfs.file.system.directory` Provides the name of the directory where the topology jar should be uploaded. The name of the directory should be unique per cluster You could use the Heron environment variables `${CLUSTER}` that will be substituted by cluster name. If this is not set, `${HOME}/.herondata/repository/${CLUSTER}/${ROLE}/${TOPOLOGY}` will be set as default. Below is an example configuration (in `uploader.yaml`) for a local file system uploader: ```yaml heron.class.uploader: org.apache.heron.uploader.localfs.LocalFileSystemUploader heron.uploader.localfs.file.system.directory: ${HOME}/.herondata/topologies/${CLUSTER} ```
Project: YugabyteDB (App Definition and Development / Database)
File: datatype-mapping-mysql.md

title: Data type mapping from MySQL to YugabyteDB linkTitle: Data type mapping description: Refer to the data type mapping table when migrating data from MySQL to YugabyteDB using YugabyteDB Voyager. menu: preview_yugabyte-voyager: identifier: datatype-mapping-mysql parent: reference-voyager weight: 102 type: docs <ul class="nav nav-tabs-alt nav-tabs-yb"> <li class="active"> <a href="../datatype-mapping-mysql/" class="nav-link"> MySQL to YugabytyeDB </a> </li> <li> <a href="../datatype-mapping-oracle/" class="nav-link"> Oracle to YugabyteDB </a> </li> </ul> The following table includes a list of supported data type mappings for migrating data from MySQL to YugabyteDB using YugabyteDB Voyager: | MySQL data type | Maps to YugabyteDB as | Description | | :-- | :- | :- | | BINARY | BYTEA | | VARBINARY | BYTEA | | BIT | BIT | | BOOLEAN | SMALLINT | As BOOLEAN type is a synonym of TINYINT(1) in , it is converted to SMALLINT in YugabyteDB, but if your use case needs it to be converted to BOOLEAN in YugabyteDB, modify the schema manually for all the respective BOOLEAN columns. | | CHAR | CHAR | | VARCHAR | VARCHAR | | TINYTEXT | TEXT | | MEDIUMTEXT | TEXT | | TEXT | TEXT | | LONGTEXT | TEXT | | TINYBLOB | BYTEA | Data is ignored during export. | | BLOB | BYTEA | Data is ignored during export. | | MEDIUMBLOB | BYTEA | Data is ignored during export. | | LONGBLOB | BYTEA | Data is ignored during export. | | DATE | DATE | | TIME | TIME WITHOUT TIMEZONE | | DATETIME | TIMESTAMP WITHOUT TIMEZONE | | TIMESTAMP | TIMESTAMP | | YEAR | SMALLINT | | DEC | DECIMAL | | DECIMAL | DECIMAL | |NUMERIC | DECIMAL | | FIXED | DECIMAL | | ENUM | ENUM | A user-defined ENUM type is created | | FLOAT | DOUBLE PRECISION | | REAL | DOUBLE PRECISION | | DOUBLE | DOUBLE PRECISION | | JSON/JSONB |JSON | | UUID | BYTEA | Not a separate datatype; it is created using functions. | | TINYINT SIGNED | SMALLINT | | TINYINT UNSIGNED | SMALLINT | | SMALLINT SIGNED | INTEGER | | SMALLINT UNSIGNED | INTEGER | | MEDUIMINT SIGNED | INTEGER | | MEDUIMINT UNSIGNED | INTEGER | | INT/INTEGER SIGNED | BIGINT | | INT/INTEGER UNSIGNED | BIGINT | | BIGINT SIGNED | BIGINT | | BIGINT UNSIGNED | NUMERIC(20) |
Project: KubeVela (App Definition and Development / Application Definition & Image Build)
File: depends-on-app.eg.md

```yaml apiVersion: core.oam.dev/v1beta1 kind: Application metadata: name: first-vela-workflow namespace: default spec: components: name: express-server type: webservice properties: image: oamdev/hello-world port: 8000 traits: type: ingress properties: domain: testsvc.example.com http: /: 8000 workflow: steps: name: express-server type: depends-on-app properties: name: another-app namespace: default ``` `depends-on-app` will check if the cluster has the application with `name` and `namespace` given in properties. If the application exists, it will hang the next step until the application is running. If the application does not exist, KubeVela will check the ConfigMap with the same name, and read the config of the Application and apply to cluster. The ConfigMap is like below: the `name` and `namespace` of the ConfigMap is the same in properties. In data, the `key` must be specified by `application`, and the `value` is the yaml of the deployed application yaml. ```yaml apiVersion: v1 kind: ConfigMap metadata: name: myapp namespace: vela-system data: application: <app yaml file> ```
Project: Operator Framework (App Definition and Development / Application Definition & Image Build)
File: doc-report.md

name: Doc Report about: Raise an issue with the documentation. title: '' labels: kind/documentation assignees: '' <!-- Please submit only documentation-related issues with this form, or follow the Contribute to Operator SDK guidelines (https://sdk.operatorframework.io/docs/contribution-guidelines/reporting-issues/) to submit a PR. Use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! --> <!-- The URL to help identify the document. --> <!-- The sections(s) within the document that have issue in. --> <!-- A clear and concise description of what the issue is. --> <!-- Add any other context about the problem here. -->
Project: CDK for Kubernetes (CDK8s) (Provisioning / Automation & Configuration)
File: chart.md

The `Chart` is a container that synthesizes a single Kubernetes manifest. ```ts class MyChart extends Chart { constructor(scope: Construct, ns: string) { super(scope, ns); // add contents here } } ``` During synthesis, charts collect all the `ApiObject` nodes (recursively) and emit a single YAML manifest that includes all these objects. When a chart is defined, you can specify chart-level `namespace` and `labels`. Those will be applied to all API objects defined within the chart (recursively): ```ts class MyChart extends Chart { constructor(scope: Construct, ns: string) { super(scope, ns, { namespace: 'my-namespace', labels: { app: 'my-app', }, }); new ApiObject(this, 'my-object', { apiVersion: 'v1', kind: 'Foo' }); } } ``` Will synthesize into: ```yaml apiVersion: v1 kind: Foo metadata: namespace: my-namespace labels: app: my-app ```