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

The following is a sample Lambda function that receives DynamoDB event data as input and writes some of the record data to CloudWatch Logs. (Note that by default anything written to Console will be logged as CloudWatch Logs.) ```go import ( "context" "fmt" "github.com/aws/aws-lambda-go/events" ) func handleRequest(ctx context.Context, e events.DynamoDBEvent) { for _, record := range e.Records { fmt.Printf("Processing request data for event ID %s, type %s.\n", record.EventID, record.EventName) // Print new values for attributes of type String for name, value := range record.Change.NewImage { if value.DataType() == events.DataTypeString { fmt.Printf("Attribute name: %s, value: %s\n", name, value.String()) } } } } ``` Stream notifications are delivered to the Lambda handler whenever data in the DynamoDB table is modified. Depending on the Stream settings, a StreamRecord may contain the following data: Keys: key attributes of the modified item. NewImage: the entire item, as it appears after it was modified. OldImage: the entire item, as it appeared before it was modified. The values for the attributes can be accessed using the AttributeValue type. For each type supported natively by DynamoDB, there is a corresponding accessor method: DynamoDB type | AttributeValue accessor method | Return type | DataType constant |--|| B (Binary) | Binary() | []byte | DataTypeBinary BOOL (Boolean) | Boolean() | bool | DataTypeBoolean BS (Binary Set)| BinarySet() | byte | DataTypeBinarySet L (List) | List() | []AttributeValue | DataTypeList M (Map) | Map() | map[string]AttributeValue | DataTypeMap N (Number) | Number() / Integer() / Float() | string / int64 / float64 | DataTypeNumber NS (Number Set)| NumberSet() | []string | DataTypeNumberSet NULL (Null) | IsNull() | bool | DataTypeNull S (String) | String() | string | DataTypeString SS (String Set)| StringSet() | []string | DataTypeStringSet Calling the accessor method for the incorrect type will result in a panic. If the type needs to be discovered in runtime, the method DataType() can be used in order to determine the correct accessor. More information about DynamoDB data types can be seen . The following example reads values of attributes name and age, for which types are known to be String and Number: ```go import ( "context" "fmt" "github.com/aws/aws-lambda-go/events" ) func handleRequest(ctx context.Context, e events.DynamoDBEvent) { for _, record := range e.Records { fmt.Printf("Processing request data for event ID %s, type %s.\n", record.EventID, record.EventName) // Print new values for attributes name and age name := record.Change.NewImage["name"].String() age, _ := record.Change.NewImage["age"].Integer() fmt.Printf("Name: %s, age: %d\n", name, age) } } ```
Project: Apache Storm (App Definition and Development / Streaming & Messaging)
File: Contributing-to-Storm.md

title: Contributing layout: documentation documentation: true Some of the issues on the are marked with the ) label. If you're interested in contributing to Storm but don't know where to begin, these are good issues to start with. These issues are a great way to get your feet wet with learning the codebase because they require learning about only an isolated portion of the codebase and are a relatively small amount of work. The section of the wiki gives detailed walkthroughs of the codebase. Reading through these docs is highly recommended to understand the codebase. Contributions to the Storm codebase should be sent as pull requests. If there's any problems to the pull request we can iterate on it using GitHub's commenting features. For small patches, feel free to submit pull requests directly for them. For larger contributions, please use the following process. The idea behind this process is to prevent any wasted work and catch design issues early on: Open an issue on the if one doesn't exist already Comment on the issue with your plan for implementing the issue. Explain what pieces of the codebase you're going to touch and how everything is going to fit together. Storm committers will iterate with you on the design to make sure you're on the right track Implement your issue, submit a pull request, and iterate from there. Modules built on top of Storm (like spouts, bolts, etc) that aren't appropriate for Storm core can be done as your own project or as part of . To be part of @stormprocessor put your project on your own Github and then send an email to the mailing list proposing to make it part of @stormprocessor. Then the community can discuss whether it's useful enough to be part of @stormprocessor. Then you'll be added to the @stormprocessor organization and can maintain your project there. The advantage of hosting your module in @stormprocessor is that it will be easier for potential users to find your project. Documentation contributions are very welcome! The best way to send contributions is as emails through the mailing list.
Project: Anchore (Provisioning / Security & Compliance)
File: ISSUE_TEMPLATE.md

<!-- Thanks for trying Anchore Engine and filing an issue! To help ensure that we can quickly and efficiently process issues and get fixes please answer a few questions--> Is this a request for help?: Is this a BUG REPORT or a FEATURE REQUEST? (choose one): <!-- If this is a BUG REPORT, please: Fill in as much of the template below as possible so we can reproduce and understand the issue. If this is a FEATURE REQUEST, please: Describe the feature in detail as much as possible including possible cli and api behavior and how to test the feature. In both cases, we'll probably ask follow-up questions to ensure it's well understood. If we cannot reproduce the issue or questions go unanswered for too long, we may close the issue. If we're wrong, PLEASE feel free to re-open it and explain why. --> <!-- To get version info: anchore-cli --version docker exec <engine_container> pip show anchore-engine --> Version of Anchore Engine and Anchore CLI if applicable: What happened: What did you expect to happen: <!-- Log output can be from the container stdout or /var/log/anchore/anchore-*. The /var/log/anchore/anchore-* logs are service specific and can help identify which components is having the issue, so please check there as well as the stdout from the container. --> Any relevant log output from /var/log/anchore: What docker images are you using: How to reproduce the issue: Anything else we need to know:
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_drop_schema.md

title: DROP SCHEMA statement [YSQL] headerTitle: DROP SCHEMA linkTitle: DROP SCHEMA description: Use the DROP SCHEMA statement to remove a schema and all of its associated objects from the system. menu: v2.18: identifier: ddldropschema parent: statements type: docs Use the `DROP SCHEMA` statement to remove a schema and all of its associated objects from the system. This is an irreversible statement. {{%ebnf%}} drop_schema {{%/ebnf%}} `DROP SCHEMA... CASCADE` executes in a single transaction so that either it has no effect (if it's interrupted) or the nominated schema together with all the objects in it are dropped. Remove a schema from the database. The schema can only be dropped by its owner or a superuser. Specify the name of the schema. Remove a schema and all associated objects. All objects that are associated with `schema_name` such as tables will be invalidated after the drop statement is completed. Refuse to drop the schema if it contains any objects. This is the default. Create a schema with a table: ```sql CREATE SCHEMA sch1; CREATE TABLE sch1.t1(id BIGSERIAL PRIMARY KEY); ``` Try to drop the schema: ```sql DROP SCHEMA sch1; ERROR: cannot drop schema sch1 because other objects depend on it DETAIL: table sch1.t1 depends on schema sch1 HINT: Use DROP ... CASCADE to drop the dependent objects too. ``` Drop a schema with `CASCADE`: ```sql DROP SCHEMA sch1 CASCADE; NOTICE: drop cascades to table sch1.t1 DROP SCHEMA ```
Project: Chef InSpec (Provisioning / Security & Compliance)
File: default.md

+++ title = "{{ or (replace .Name "_" " ") (replace .Name "-" " ") | title }}" draft = false gh_repo = "inspec" [menu] [menu.inspec] title = "{{ replace .Name "-" " " | title }}" identifier = "inspec/{{ .Name }}.md {{ or (replace .Name "_" " ") (replace .Name "-" " ") | title }}" parent = "inspec" weight = 10 +++
Project: Tetragon (Provisioning / Security & Compliance)
File: privileged-execution.md

title: "Privileged execution" weight: 3 description: "Monitor process capabilities and kernel namespace access" Tetragon also provides the ability to check process capabilities and kernel namespaces access. This information would help us determine which process or Kubernetes pod has started or gained access to privileges or host namespaces that it should not have. This would help us answer questions like: Which Kubernetes pods are running with `CAPSYSADMIN` in my cluster? Which Kubernetes pods have host network or pid namespace access in my cluster? Edit the Tetragon configmap: ```bash kubectl edit cm -n kube-system tetragon-config ``` Set the following flags from "false" to "true": ```bash ``` Save your changes and exit. Restart the Tetragon daemonset: ```bash kubectl rollout restart -n kube-system ds/tetragon ``` Create a YAML file (e.g., privileged-nginx.yaml) with the following PodSpec: ```yaml apiVersion: v1 kind: Pod metadata: name: privileged-the-pod spec: hostPID: true hostNetwork: true containers: name: privileged-the-pod image: nginx:latest ports: containerPort: 80 securityContext: privileged: true ``` Apply the configuration: ```bash kubectl apply -f privileged-nginx.yaml ``` Start monitoring events from the privileged Nginx pod: ```bash kubectl logs -n kube-system -l app.kubernetes.io/name=tetragon -c export-stdout -f | tetra getevents --namespace default --pod privileged-the-pod ``` You should observe Tetragon generating events similar to these, indicating the privileged container start: ```bash process default/privileged-nginx /nginx -g daemon off; CAPSYSADMIN ```
Project: Meshery (Provisioning / Automation & Configuration)
File: kubevault-catalog.md

layout: integration title: Kubevault Catalog subtitle: Collaborative and visual infrastructure as code for Kubevault Catalog image: /assets/img/integrations/kubevault-catalog/icons/color/kubevault-catalog-color.svg permalink: extensibility/integrations/kubevault-catalog docURL: https://docs.meshery.io/extensibility/integrations/kubevault-catalog description: integrations-category: Security & Compliance integrations-subcategory: Uncategorized registrant: Artifact Hub components: name: vault-server-version colorIcon: assets/img/integrations/kubevault-catalog/components/vault-server-version/icons/color/vault-server-version-color.svg whiteIcon: assets/img/integrations/kubevault-catalog/components/vault-server-version/icons/white/vault-server-version-white.svg description: featureList: [ "Deploy TLS secured Vault Servers on Kubernetes using KubeVault. You can use cert-manager to manage VaultServer TLS or you can manage TLS with self-signed.", "Invite anyone to review and make changes to your private designs.", "Ongoing synchronization of Kubernetes configuration and changes across any number of clusters." ] howItWorks: "Collaborative Infrastructure as Code" howItWorksDetails: "Collaboratively manage infrastructure with your coworkers synchronously sharing the same designs." language: en list: include type: extensibility category: integrations
Project: CloudEvents (App Definition and Development / Streaming & Messaging)
File: open-source.md

If you have created (or know of) an open source library or product that uses CloudEvents v1.0, please include it in the list below. : An event-based dependency manager for Kubernetes which uses sensors to act on CloudEvents. is a JavaScript programming model for Extend which allows handling CloudEvents. : A CloudEvents library for Node.js. : Visual Studio Code extension for CloudEvents format. : A CloudEvents library for python. : is a tool to help verify CloudEvents according to the proper specifications. It is currently being hosted publicly . : is a function gateway built on top of by that supports CloudEvents. implements CloudEvents based sources and event delivery abstractions build on top of Kubernetes. is a Cloud Native Computing dedicated to API Mocking and Testing. See our CloudEvents integration . enables event driven workflows from vCenter Server Events.
Project: YDB (App Definition and Development / Database)
File: pragmatablepathprefix.md

`PRAGMA TablePathPrefix` adds a specified prefix to the database table paths. It uses standard file system path concatenation: i.e., it supports parent folder referencing and requires no trailing slash. For example: ```sql PRAGMA TablePathPrefix = "/cluster/database"; SELECT * FROM episodes; ``` For more information about PRAGMA in YQL, see the .
Project: Backstage (App Definition and Development / Application Definition & Image Build)
File: writing-custom-step-layouts.md

id: writing-custom-step-layouts title: Writing custom step layouts description: How to override the default step form layout Every form in each step rendered in the frontend uses the default form layout from . It is possible to override this behaviour by supplying a `ui:ObjectFieldTemplate` property for a particular step: ```yaml parameters: title: Fill in some steps ui:ObjectFieldTemplate: TwoColumn ``` This is the same used by but we need to add a couple of steps to ensure that the string value of `TwoColumn` above is resolved to a react component. The function is used to mark a component as a custom step layout: ```ts import React from 'react'; import { scaffolderPlugin } from '@backstage/plugin-scaffolder'; import { createScaffolderLayout, LayoutTemplate, } from '@backstage/plugin-scaffolder-react'; import { Grid } from '@material-ui/core'; const TwoColumn: LayoutTemplate = ({ properties, description, title }) => { const mid = Math.ceil(properties.length / 2); return ( <> <h1>{title}</h1> <h2>In two column layout!!</h2> <Grid container justifyContent="flex-end"> {properties.slice(0, mid).map(prop => ( <Grid item xs={6} key={prop.content.key}> {prop.content} </Grid> ))} {properties.slice(mid).map(prop => ( <Grid item xs={6} key={prop.content.key}> {prop.content} </Grid> ))} </Grid> {description} </> ); }; export const TwoColumnLayout = scaffolderPlugin.provide( createScaffolderLayout({ name: 'TwoColumn', component: TwoColumn, }), ); ``` After you have registered your component as a custom layout then you need to provide the `layouts` to the `ScaffolderPage`: ```tsx import { MyCustomFieldExtension } from './scaffolder/MyCustomExtension'; import { TwoColumnLayout } from './components/scaffolder/customScaffolderLayouts'; const routes = ( <FlatRoutes> ... <Route path="/create" element={<ScaffolderPage />}> <ScaffolderLayouts> <TwoColumnLayout /> </ScaffolderLayouts> </Route> ... </FlatRoutes> ); ``` Any component that has been passed to the `ScaffolderPage` as children of the `ScaffolderLayouts` component can be used as a `ui:ObjectFieldTemplate` in your template file: ```yaml parameters: title: Fill in some steps ui:ObjectFieldTemplate: TwoColumn ```
Project: StarRocks (App Definition and Development / Database)
File: routines.md

displayed_sidebar: "English" `routines` contains all stored routines (stored procedures and stored functions). The following fields are provided in `routine`: | Field | Description | | -- | | | SPECIFIC_NAME | The name of the routine. | | ROUTINE_CATALOG | The name of the catalog to which the routine belongs. This value is always `def`. | | ROUTINE_SCHEMA | The name of the database to which the routine belongs. | | ROUTINE_NAME | The name of the routine. | | ROUTINE_TYPE | `PROCEDURE` for stored procedures, `FUNCTION` for stored functions. | | DTD_IDENTIFIER | If the routine is a stored function, the return value data type. If the routine is a stored procedure, this value is empty. | | ROUTINE_BODY | The language used for the routine definition. This value is always `SQL`. | | ROUTINE_DEFINITION | The text of the SQL statement executed by the routine. | | EXTERNAL_NAME | This value is always `NULL`. | | EXTERNAL_LANGUAGE | The language of the stored routine. | | PARAMETER_STYLE | This value is always `SQL`. | | IS_DETERMINISTIC | `YES` or `NO`, depending on whether the routine is defined with the `DETERMINISTIC` characteristic. | | SQLDATAACCESS | The data access characteristic for the routine. The value is one of `CONTAINS SQL`, `NO SQL`, `READS SQL DATA`, or `MODIFIES SQL DATA`. | | SQL_PATH | This value is always `NULL`. | | SECURITY_TYPE | The routine `SQL SECURITY` characteristic. The value is one of `DEFINER` or `INVOKER`. | | CREATED | The date and time when the routine was created. This is a `DATETIME` value. | | LAST_ALTERED | The date and time when the routine was last modified. This is a `DATETIME` value. If the routine has not been modified since its creation, this value is the same as the `CREATED` value. | | SQL_MODE | The SQL mode in effect when the routine was created or altered, and under which the routine executes. | | ROUTINE_COMMENT | The text of the comment, if the routine has one. If not, this value is empty. | | DEFINER | The user named in the `DEFINER` clause (often the user who created the routine). | | CHARACTERSETCLIENT | | | COLLATION_CONNECTION | | | DATABASE_COLLATION | The collation of the database with which the routine is associated. |
Project: Juju (Provisioning / Automation & Configuration)
File: PULL_REQUEST_TEMPLATE.md

<!-- Why this change is needed and what it does. --> <!-- If an item is not applicable, use `~strikethrough~`. --> [ ] Code style: imports ordered, good names, simple structure, etc [ ] Comments saying why design decisions were made [ ] Go unit tests, with comments saying what you're testing , with comments saying what you're testing added or updated in changed packages <!-- Describe steps to verify that the change works. --> <!-- How it affects user workflow (CLI or API). --> <!-- Link to all relevant specification, documentation, bug, issue or JIRA card. --> Launchpad bug: https://bugs.launchpad.net/juju/+bug/ Jira card: JUJU-
Project: KICS (Provisioning / Security & Compliance)
File: c7fc1481-2899-4490-bbd8-544a3a61a2f3.md

title: App Service Authentication Disabled hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: c7fc1481-2899-4490-bbd8-544a3a61a2f3 Query name: App Service Authentication Disabled Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Access Control URL: Azure App Service authentication settings should be enabled<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "azurermappservice" "positive1" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" } app_settings = { "SOME_KEY" = "some-value" } connection_string { name = "Database" type = "SQLServer" value = "Server=some-server.mydomain.com;Integrated Security=SSPI" } } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="17" resource "azurermappservice" "positive2" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" } app_settings = { "SOME_KEY" = "some-value" } auth_settings = { enabled = false } connection_string { name = "Database" type = "SQLServer" value = "Server=some-server.mydomain.com;Integrated Security=SSPI" } } ``` ```tf title="Negative test num. 1 - tf file" resource "azurermappservice" "negative1" { name = "example-app-service" location = azurermresourcegroup.example.location resourcegroupname = azurermresourcegroup.example.name appserviceplanid = azurermappserviceplan.example.id site_config { dotnetframeworkversion = "v4.0" scm_type = "LocalGit" } app_settings = { "SOME_KEY" = "some-value" } auth_settings = { enabled = true } connection_string { name = "Database" type = "SQLServer" value = "Server=some-server.mydomain.com;Integrated Security=SSPI" } } ```
Project: Docker Compose (App Definition and Development / Application Definition & Image Build)
File: compose_alpha.md

<!MARKERGENSTART--> Experimental commands | Name | Description | |:-|:--| | | EXPERIMENTAL - Generate a graphviz graph from your compose file | | | EXPERIMENTAL - Watch build context for service and rebuild/refresh containers when files are updated | | Name | Type | Default | Description | |:|:--|:--|:--| | `--dry-run` | | | Execute command in dry run mode | <!MARKERGENEND-->
Project: YugabyteDB (App Definition and Development / Database)
File: ddl_drop_procedure.md

title: DROP PROCEDURE statement [YSQL] headerTitle: DROP PROCEDURE linkTitle: DROP PROCEDURE description: Use the DROP PROCEDURE statement to remove a procedure from a database. menu: v2.18: identifier: ddldropprocedure parent: statements type: docs Use the `DROP PROCEDURE` statement to remove a procedure from a database. {{%ebnf%}} drop_procedure, subprogram_signature, arg_decl {{%/ebnf%}} You must identify the to-be-dropped procedure by: Its name and the schema where it lives. This can be done by using its fully qualified name or by using just its bare name and letting name resolution find it in the first schema on the searchpath_ where it occurs. Notice that you don't need to (and cannot) mention the name of its owner. Its signature. The is sufficient; and this is typically used. You can use the full subprogramsignature. But you should realize that the argname and argmode for each argdecl carry no identifying information. (This is why it is not typically used when a function or procedure is to be altered or dropped.) This is explained in the section . An error will be thrown if the procedure does not exist unless `IF EXISTS` is used. Then a notice is issued instead. `RESTRICT` is the default and it will not drop the procedure if any objects depend on it. `CASCADE` will drop any objects that transitively depend on the procedure. ```plpgsql DROP PROCEDURE IF EXISTS transfer(integer, integer, dec) CASCADE; ```