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

Headlamp plugins repositories are expected to be hosted in GitHub, GitLab or Bitbucket repos. When adding your repository to Artifact Hub, the url used must follow the following format: `https://github.com/user/repo[/path/to/packages]` `https://gitlab.com/user/repo[/path/to/packages]` `https://bitbucket.org/user/repo[/path/to/packages]` By default the `master` branch is used, but it's possible to specify a different one from the UI. Please NOTE that the repository URL used when adding the repository to Artifact Hub must NOT contain the git hosting platform specific parts, like tree/branch, just the path to your packages like it would show in the filesystem. The path/to/packages provided can contain metadata for one or more packages. Each package version must be on a separate folder, and it's up to you to decide if you want to publish one or multiple versions of your package. The structure of a repository with multiple plugins packages and versions could look something like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 1.0.0 README.md artifacthub-pkg.yml 2.0.0 README.md artifacthub-pkg.yml package2 1.0.0 README.md artifacthub-pkg.yml ``` This structure is flexible, and in some cases where you only have a package and a version it can be greatly simplified. In the case of a single package with a single version available at a time (the publisher doesn't want to make previous ones available, for example), the structure could look like this: ```sh $ tree path/to/packages path/to/packages artifacthub-repo.yml package1 README.md artifacthub-pkg.yml ``` In the previous case, even the `package1` directory could be omitted. The reason is that both packages names and versions are read from the `artifacthub-pkg.yml` metadata file, so directories names are not used at all. Each package version needs an `artifacthub-pkg.yml` metadata file. Please see the file and the for more details. The repository metadata file shown above can be used to setup features like or . This file must be located at `/path/to/packages`. Once you have added your repository, you are all set up. As you add new versions of your plugins packages or new packages to your git repository, they'll be automatically indexed and listed in Artifact Hub.
Project: Databend (App Definition and Development / Database)
File: workflows.md

Databend make new releases via workflow . There are three ways to trigger a new release: Push a new tag On Schedule (every day at 00:00 UTC+8) Manually triggered If new tags pushed, we use this the new tag name as release name. Otherwise, we will generate a new nightly tag. For example: If current latest release is `v0.7.0`, we will generate a nightly tag `v0.7.1-nightly` If current latest release is `v0.7.10-nightly`, we will generate a new tag `v0.7.11-nightly` For every release, we will: Create a new release on GitHub. Build binaries and pack them on Linux and MacOS. Upload built packages to GitHub Releases, AWS S3 bucket and Docker Registry. We are adopting github native release notes generation which controlled by .
Project: StarRocks (App Definition and Development / Database)
File: to_days.md

displayed_sidebar: "English" Returns the number of days between a date and 0000-01-01. The `date` parameter must be of the DATE or DATETIME type. ```Haskell INT TO_DAYS(DATETIME date) ``` ```Plain Text MySQL > select to_days('2007-10-07'); +--+ | to_days('2007-10-07') | +--+ | 733321 | +--+ ``` TO_DAYS,TO,DAYS
Project: GraphScope (App Definition and Development / Database)
File: tinkerpop_eco.md

GIE is a system that seamlessly integrates with the ) ecosystem, which is an open framework for developing interactive graph applications using the gremlin query language. By implementing TinkerPop's gremlin ) interface, GIE allows for easy interaction with client/development tools such as gremlin console and language wrappers such as Java and Python. The following documentations will guide you through empowering the Tinkerpop ecosystem with GIE's distributed capability for large-scale graph. ```{toctree} arguments caption: GIE For Tinkerpop Ecosystem maxdepth: 2 tinkerpop/tinkerpop_gremlin tinkerpop/guideandexamples tinkerpop/supportedgremlinsteps tinkerpop/faq ```
Project: Meshery (Provisioning / Automation & Configuration)
File: mesheryctl-exp-relationship-generate.md

layout: default title: mesheryctl-exp-relationship-generate permalink: reference/mesheryctl/exp/relationship/generate redirect_from: reference/mesheryctl/exp/relationship/generate/ type: reference display-title: "false" language: en command: exp subcommand: relationship generate relationships docs generate relationships docs from the google spreadsheets <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl exp relationship generate [flags] </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> // generate relationships docs </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> mesheryctl relationships generate $CRED </div> </pre> <pre class='codeblock-pre'> <div class='codeblock'> -h, --help help for generate -s, --sheetId string Google Sheet ID </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: YDB (App Definition and Development / Database)
File: select_right_join_output.md

``` name | lastname | socialcardnumber +-+-- John | Doe | 123456789 Jane | Smith | 223456789 Alice | Johnson | 323456789 Bob | Brown | 423456789 Charlie | Davis | 523456789 Eve | Martin | 623456789 | | 723456789 ```
Project: Artifact Hub (App Definition and Development / Application Definition & Image Build)
File: kyverno_annotations.md

You can provide some extra information about your Kyverno policies by using the `annotations` field in the . kyverno/category (string) Category the policy fits in. Unless the policy applies to a community or "external" Kubernetes project, use other. kyverno/kubernetesVersion (string) Version(s) of Kubernetes against which the policy should work. Value should ideally be a range of versions no more than two prior (ex., 1.19-1.21) and must be enclosed in quotes. kyverno/subject (string) The focus of the policy. For example, Pod or Ingress or a CustomResource like ClusterIssuer. The subject is the "thing" on which the policy operates. For multiple, use a comma-separated string like Pod, Deployment. kyverno/version (string) Minimum version of Kyverno where this policy works. Note that this isn't the version of Kyverno where it was developed or tested but the minimum version of Kyverno where it's supported. If unknown, omit. ```yaml ... annotations: kyverno/category: "OpenShift" kyverno/kubernetesVersion: "1.20" kyverno/subject: "Route" kyverno/version: "1.6.0" ```
Project: KICS (Provisioning / Security & Compliance)
File: 66477506-6abb-49ed-803d-3fa174cd5f6a.md

title: Launch Configuration Is Not Encrypted hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: 66477506-6abb-49ed-803d-3fa174cd5f6a Query name: Launch Configuration Is Not Encrypted Platform: Ansible Severity: <span style="color:#bb2124">High</span> Category: Encryption URL: Launch Configurations should have the data in the volumes encrypted. To encrypt the data, the 'encrypted' parameter should be set to true in each volume<br> ```yaml title="Positive test num. 1 - yaml file" hl_lines="8 29 22" name: note that encrypted volumes are only supported in >= Ansible 2.4 community.aws.ec2_lc: name: special image_id: ami-XXX key_name: default security_groups: ['group', 'group2' ] instance_type: t1.micro volumes: device_name: /dev/sda1 volume_size: 100 volume_type: io1 iops: 3000 deleteontermination: true encrypted: no name: note that encrypted volumes are only supported in >= Ansible 2.4 v2 ec2_lc: name: special image_id: ami-XXX key_name: default security_groups: ['group', 'group2' ] instance_type: t1.micro volumes: device_name: /dev/sda1 volume_size: 100 volume_type: io1 iops: 3000 deleteontermination: true name: note that encrypted volumes are only supported in >= Ansible 2.4 v3 ec2_lc: name: special image_id: ami-XXX key_name: default security_groups: ['group', 'group2' ] instance_type: t1.micro ``` ```yaml title="Negative test num. 1 - yaml file" name: note that encrypted volumes are only supported in >= Ansible 2.4 v4 ec2_lc: name: special image_id: ami-XXX key_name: default security_groups: [group, group2] instance_type: t1.micro volumes: device_name: /dev/sda1 volume_size: 100 volume_type: io1 iops: 3000 deleteontermination: true encrypted: yes name: note that encrypted volumes are only supported in >= Ansible 2.4 v5 community.aws.ec2_lc: name: special image_id: ami-XXX key_name: default security_groups: [group, group2] instance_type: t1.micro volumes: device_name: /dev/sda1 volume_size: 100 volume_type: io1 iops: 3000 deleteontermination: true encrypted: yes ```
Project: SPIFFE (Provisioning / Key Management)
File: GERI_JENNINGS.md

Geri is an engineering manager who has been involved in SPIFFE and SPIRE since her time at CyberArk, in particular working on the adjacent products Conjur and Secretless. I believe she'd make an excellent SSC member due to (a) her domain experience in authentication and secrets management, (b) her experience in catalysing and maintaining open-source communities, and (c) her continued passion and investment in the SPIFFE project. Geri answered the following questions in support of her nomination. What makes you a good fit for the SPIFFE Steering Committee? I first became aware of SPIFFE / SPIRE when I joined the CNCF Security SIG in April 2018. At the time, I was working as a software engineer building a transparent authentication proxy that CyberArk eventually released as Secretless Broker. I joined the CNCF Security SIG so that I could be a part of the conversations happening around cloud-native security, and I found in SPIFFE a project that used familiar terminology (like zero trust and least privilege) to describe the ideal, safe, developer-friendly path forward. In my work over the past several years as a cloud-native vendor, the central role that SPIFFE / SPIRE play in the cloud-native security landscape has become clear. In the end, privileged access management in dynamic, modern environments isn't possible without a mechanism to identify the workloads running in these environments - or put another way, modern access control requires a modern mechanism for defining what a workload's identity is. What aspects of SSC participation are you most excited about? I've always appreciated and respected the work of the SPIFFE team, and have looked for opportunities to personally contribute. With the creation of the SSC I am happy to have found something that will use my skills! The work ahead of the group is very much in line with my recent experience as an engineering manager responsible for building the open source program at CyberArk. I am eager to engage with the SPIFFE community and to collaborate with the SSC members on defining the mission and values, tracking the progress and goals, and building the governance model. Is there anything else you'd like to say as part of your nomination? I'm really grateful to be nominated, and I am excited for the chance to serve on the SPIFFE Steering Committee! GitHub Handle: @izgeri Email Address: izbicki@gmail.com LinkedIn Profile: https://www.linkedin.com/in/geri-jennings/ Current Affiliation: Salsify
Project: StarRocks (App Definition and Development / Database)
File: function-list.md

displayed_sidebar: "English" StarRocks offers a rich set of functions to facilitate data queries and analysis. In addition to commonly used functions, StarRocks supports semi-structured functions such as ARRAY, JSON, MAP, and STRUCT functions. It also supports higher-order . If these functions cannot meet your business requirements, you can use to compile functions. StarRocks also provides . You can generate Bitmap data in Hive and then load Bitmap into StarRocks. You can also export the Bitmap data generated in StarRocks to Hive for other systems to use. You can find a built-in function based on the following categories: - - - - - - - - - - -
Project: Trivy (Provisioning / Security & Compliance)
File: trivy_plugin.md

Manage plugins ``` -h, --help help for plugin ``` ``` --cache-dir string cache directory (default "/path/to/cache") -c, --config string config path (default "trivy.yaml") -d, --debug debug mode --generate-default-config write the default config to trivy-default.yaml --insecure allow insecure server connections -q, --quiet suppress progress bar and log output --timeout duration timeout (default 5m0s) -v, --version show version ``` - Unified security scanner - Show information about the specified plugin - Install a plugin - List installed plugin - Run a plugin on the fly - List Trivy plugins available on the plugin index and search among them - Uninstall a plugin - Update the local copy of the plugin index - Upgrade installed plugins to newer versions
Project: cert-manager (Provisioning / Security & Compliance)
File: 20191218-security-context-deprecation.md

The idea is to be able to define a `securityContext` from an arbitrary yaml block without being restricted to just the attributes currently supported. For example, by supporting a block like the following in the `values.yaml` file: ```yaml securityContext: fsGroup: 1111 runAsUser: 2222 runAsNonRoot: true ``` The logic for supporting the new `securityContext` in the `values.yaml` file should be backwards compatible with the `securityContext.enabled` parameter. No security context block should be defined if: ``` securityContext is empty or securityContext.enabled is defined and securityContext.enabled is false ``` Otherwise a securityContext block should be defined When a securityContext block has to be generated, we should fall back and support the deprecated structure if: ``` securityContext.enabled is true ``` Otherwise, we copy the `securityContext` block as it is to support the new format. Defaults Input: No security context specified Output: Nothing generated Legacy parameters with `enabled` only and no additional parameters Input: ```yaml securityContext: enabled: true ``` Output: ```yaml securityContext: fsGroup: 1001 runAsUser: 1001 ``` Legacy parameters with `enabled`, group and user Input: ```yaml securityContext: enabled: true fsGroup: 1111 runAsUser: 2222 ``` Output: ```yaml securityContext: fsGroup: 1111 runAsUser: 2222 ``` New default format Input: ```yaml securityContext: {} ``` Output: ```yaml ``` New format with arbitrary block Input: ```yaml securityContext: fsGroup: 1111 runAsUser: 2222 runAsNonRoot: true ``` Output: ```yaml securityContext: fsGroup: 1111 runAsNonRoot: true runAsUser: 2222 ``` Legacy parameters with `enabled` set to false and extra parameters that should be ignored Input: ```yaml securityContext: enabled: false fsGroup: 1111 runAsUser: 2222 ``` Output: ```yaml ``` Legacy parameters with `enabled` set to false Input: ```yaml securityContext: enabled: false ``` Output: ```yaml ``` Block with only fsGroup and runAsUser Input: ```yaml securityContext: fsGroup: 1111 runAsUser: 2222 ``` Output: ```yaml securityContext: fsGroup: 1111 runAsUser: 2222 ```
Project: KICS (Provisioning / Security & Compliance)
File: ed6e3ba0-278f-47b6-a1f5-173576b40b7e.md

title: CMK Is Unusable hide: toc: true navigation: true <style> .highlight .hll { background-color: #ff171742; } .md-content { max-width: 1100px; margin: 0 auto; } </style> Query id: ed6e3ba0-278f-47b6-a1f5-173576b40b7e Query name: CMK Is Unusable Platform: Terraform Severity: <span style="color:#ff7213">Medium</span> Category: Availability URL: Alicloud KMS must only possess usable Customer Master Keys (CMK), which means the CMKs must have the attribute 'is_enabled' set to true<br> ```tf title="Positive test num. 1 - tf file" hl_lines="1" resource "alicloudkmskey" "key" { description = "Hello KMS" pendingwindowin_days = "7" status = "Enabled" } ``` ```tf title="Positive test num. 2 - tf file" hl_lines="5" resource "alicloudkmskey" "key" { description = "Hello KMS" pendingwindowin_days = "7" status = "Enabled" is_enabled = false } ``` ```tf title="Negative test num. 1 - tf file" resource "alicloudkmskey" "key" { description = "Hello KMS" pendingwindowin_days = "7" status = "Enabled" is_enabled = true } ```
Project: Buildpacks (App Definition and Development / Application Definition & Image Build)
File: CONTRIBUTING.md

We're glad you are interested in contributing to this project. We hope that this document helps you get started. This repository adheres to the following project policies: - How we should act with each other. - General contributing standards. - Reporting security concerns. - Getting support. Aside from the policies above, you may find to provide specific helpful detail to assist you while developing in this repository. We welcome any and all contributions! The issues we are prioritizing are visible in the repository , and we especially welcome contributions to that. One good place to start contributing is in our , though you are welcome to start in this repository! After making all the changes but before creating a , you should run `make prepare-for-pr`. This command runs a set of other tasks that resolve or report any simple issues that would otherwise arise during the pull request review process. Running user acceptance on a pull request is just as critical as reviewing the code changes. It allows you, a contributor and user, direct insight into how a feature works and allows for you to provide feedback into what could be improved. On GitHub's Pull Request view, click on the Checks tab. On the left panel, click on the build step. On the bottom, there is Artifacts section. Click on the zip file for the platform you are running. Unzip binary: ```shell unzip pack-{{PLATFORM}}.zip ``` Enable execution of binary (macOS/Linux only): ```shell chmod +x ./pack ``` > For macOS, you might need to allow your terminal to be able to execute applications from unverified developers. See . > > A quick solution is to add exception to the downloaded pack binary: `sudo spctl --add -v ./pack` You should now be able to execute pack via: macOS: `./pack` Linux: `./pack` Windows: `pack.exe` When providing feedback please provide a succinct title, a summary of the observation, what you expected, and some output or screenshots. Here's a simple template you can use: ```text <!-- a summary of what you observed --> <!-- describe what you expected --> <!-- output / logs / screenshots --> ```
Project: Meshery (Provisioning / Automation & Configuration)
File: piraeus-datastore.md

layout: integration title: Piraeus Datastore subtitle: Collaborative and visual infrastructure as code for Piraeus Datastore image: /assets/img/integrations/piraeus-datastore/icons/color/piraeus-datastore-color.svg permalink: extensibility/integrations/piraeus-datastore docURL: https://docs.meshery.io/extensibility/integrations/piraeus datastore description: integrations-category: Cloud Native Storage integrations-subcategory: Database registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "DRBD-9 has great data replication efficiency. It provides synchronous,semi-synchronous and asynchronous replication schemes, and also supports RDMA for high-speed across-node connection.", "Supports 1/2/3 replica numbers for persistent volumes. Piraeus place the replicas intelligently across the nodes to balance the workload." ] howItWorks: "Piraeus can run on all kinds of storage medium: RAID, SAN, NAS or EBS" howItWorksDetails: "It deploys and scales out automatically within Kubernetes nodes. With Piraeus, Kubernetes workloads can now consume high performance local storage using the same volume APIs that app developers have become accustomed to." language: en list: include type: extensibility category: integrations
Project: SlimToolkit (Provisioning / Security & Compliance)
File: SECURITY.md

Join the [kubernetes-security-announce] group for security and vulnerability announcements. You can also subscribe to an RSS feed of the above using . Instructions for reporting a vulnerability can be found on the [Kubernetes Security and Disclosure Information] page. Information about supported Kubernetes versions can be found on the [Kubernetes version and version skew support policy] page on the Kubernetes website.
Project: Meshery (Provisioning / Automation & Configuration)
File: emissary-ingress.md

layout: integration title: Emissary Ingress subtitle: Collaborative and visual infrastructure as code for Emissary Ingress image: /assets/img/integrations/emissary-ingress/icons/color/emissary-ingress-color.svg permalink: extensibility/integrations/emissary-ingress docURL: https://docs.meshery.io/extensibility/integrations/emissary-ingress description: integrations-category: Cloud Native Network integrations-subcategory: Service Proxy registrant: Artifact Hub components: featureList: [ "Drag-n-drop cloud native infrastructure designer to configure, model, and deploy your workloads.", "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