Full Code of score-spec/spec for AI

Repository: score-spec/spec
Branch: main
Commit: 4ecf524c1729
Files: 26
Total size: 61.5 KB

Directory structure:
gitextract_rei917y2/

├── .github/
│   ├── ISSUE_TEMPLATE/
│   │   ├── bug_report.yml
│   │   ├── config.yml
│   │   ├── documentation.yml
│   │   ├── feature_request.yml
│   │   └── other.yml
│   ├── PULL_REQUEST_TEMPLATE.md
│   ├── dependabot.yml
│   └── workflows/
│       ├── ci.yaml
│       ├── dependabot-auto-merge.yaml
│       └── release.yaml
├── .gitignore
├── .lycheeignore
├── ADOPTERS.md
├── CODEOWNERS
├── CODE_OF_CONDUCT.md
├── CONTRIBUTING.md
├── GOVERNANCE.md
├── LICENSE
├── MAINTAINERS.md
├── Makefile
├── README.md
├── SECURITY.md
├── roadmap.md
├── samples/
│   ├── score-deprecated-files-and-volumes.yaml
│   └── score-full.yaml
└── score-v1b1.json

================================================
FILE CONTENTS
================================================

================================================
FILE: .github/ISSUE_TEMPLATE/bug_report.yml
================================================
name: Bug report
description: Create a report to help us improve. Report bugs found while using the project
title: "[BUG] <title>"
labels: [bug]
body:
  - type: textarea
    id: description
    attributes:
      label: Description
      description: A clear and concise description of what the bug is.
    validations:
      required: true
  - type: textarea
    id: expectedbhv
    attributes:
      label: Expected behavior
      description: A clear and concise description of what you expected to happen.
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
      description: |
         Provide a link to a live example, or an unambiguous set of steps to
         reproduce this bug. Include code to reproduce, if relevant
      placeholder: |
        1.
        2.
        3.
        4.
    validations:
      required: false
  - type: textarea
    id: screenshots
    attributes:
      label: Screenshots
      description: If applicable, add screenshots to help explain your problem.
  - type: textarea
    id: context
    attributes:
      label: Context
      description: How has this bug affected you? What were you trying to accomplish?
    validations:
      required: true
  - type: textarea
    id: extra_information
    attributes:
      label: Additional information
      description: Is there anything else we should know about this bug?
    validations:
      required: false


================================================
FILE: .github/ISSUE_TEMPLATE/config.yml
================================================
blank_issues_enabled: false


================================================
FILE: .github/ISSUE_TEMPLATE/documentation.yml
================================================
name: "Documentation report"
description: "Report any documentation bugs, improvements, or changes you want to suggest."
title: "[DOCS] <description>"
labels: [documentation]
assignees: rachfop
body:
  - type: textarea
    id: description
    attributes:
      label: Description
      description: |
        Describe if you've found a documentation error or if you want to make an improvement.
        If you've found a bug, specify in what file the bug is and if possible, add a link.
    validations:
      required: true
  - type: textarea
    id: context
    attributes:
      label: Context
      description: |
        Applies only if it's a new documentation file, new guidelines, etc..
        Why should this be added? In what way would it benefit others and you?
    validations:
      required: false # If they're reporting a bug, this section does not fit for that.
  - type: textarea
    id: additional_information
    attributes:
      label: Additional information
      description: Is there anything else you'd like to mention about this issue?
    validations:
      required: false


================================================
FILE: .github/ISSUE_TEMPLATE/feature_request.yml
================================================
name: Feature request
description: Suggest features, propose improvements, discuss new ideas.
title: "[FEATURE] <title>"
labels: [feature]
body:
  - type: textarea
    id: description
    attributes:
      label: Detailed description
      description: A clear and concise description of what the problem is.
      placeholder: Ex. I'm always frustrated when [...]
    validations:
      required: true
  - type: textarea
    id: context
    attributes:
      label: Context
      description: |
        Why is this change important to you? How would you use it?
        How can it benefit other users?
    validations:
      required: true
  - type: textarea
    id: possible_implementation
    attributes:
      label: Possible implementation
      description: Suggest an idea for implementing the addition/change and its alternatives
    validations:
      required: true
  - type: textarea
    id: extra_information
    attributes:
      label: Additional information
      description: Is there anything else we should know about this feature?
    validations:
      required: false


================================================
FILE: .github/ISSUE_TEMPLATE/other.yml
================================================
name: Other
description: Use this for any other issues. Do NOT create blank issues
title: "[OTHER] <description>"
labels: ["awaiting triage"] # Requires a new label to be created
body:
  - type: markdown
    attributes:
      value: |
        Please make sure your issue does not fit in any of the provided templates.
        If so, choose the most appropriate one for your issue.
  - type: textarea
    id: issuedescription
    attributes:
      label: What would you like to share?
      description: Provide a clear and concise explanation of your issue.
    validations:
      required: true
  - type: textarea
    id: extrainfo
    attributes:
      label: Additional information
      description: Is there anything else we should know about this issue?
    validations:
      required: false


================================================
FILE: .github/PULL_REQUEST_TEMPLATE.md
================================================
<!--- Provide a general summary of your changes in the Title above -->

#### Description

<!--- Describe your changes in detail -->

#### What does this PR do?

<!--- Why is this change required? What problem does it solve? -->
<!--- If it fixes an open issue, please link to the issue here. -->

#### Types of changes

<!--- What types of changes does your code introduce? Put an `x` in all the boxes that apply: -->

- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] New chore (expected functionality to be implemented)

#### Checklist:

<!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
<!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->

- [ ] My change requires a change to the documentation.
  - [ ] I have updated the documentation accordingly.
- [ ] I've signed off with an email address that matches the commit author.


================================================
FILE: .github/dependabot.yml
================================================
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      ci:
        patterns:
          - "*"


================================================
FILE: .github/workflows/ci.yaml
================================================
---
name: "CI"

on:
  push:
    branches: main
  pull_request: {}

permissions:
  contents: read

jobs:
  linkchecker:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
      - name: Link Checker
        uses: lycheeverse/lychee-action@a8c4c7cb88f0c7386610c35eb25108e448569cb0 # v2.7.0
        with:
          args: --verbose --no-progress './**/*.md' './**/*.html'
          fail: true
        env:
          GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

  jsonschema:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
      - name: Setup Go
        uses: actions/setup-go@7a3fe6cf4cb3a834922a1244abfce67bcef6a0c5 # v6.2.0
        with:
          go-version: 'stable'
      - name: Check Schema
        env:
          GOPATH: /home/runner/work/go
        run: make test


================================================
FILE: .github/workflows/dependabot-auto-merge.yaml
================================================
name: Dependabot auto-merge
on: pull_request
permissions:
  contents: read
jobs:
  dependabot-auto-merge:
    runs-on: ubuntu-latest
    permissions:
      contents: write
      pull-requests: write
    if: ${{ github.actor == 'dependabot[bot]' && !github.event.pull_request.auto_merge }}
    steps:
      - name: Approve a PR
        run: gh pr review --approve "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - name: Enable auto-merge for Dependabot PRs
        run: gh pr merge --auto --squash "$PR_URL"
        env:
          PR_URL: ${{github.event.pull_request.html_url}}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}


================================================
FILE: .github/workflows/release.yaml
================================================
name: Release
on:
  release:
    types: [published]
permissions:
  contents: read
jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
    - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
    - name: Release
      uses: softprops/action-gh-release@a06a81a03ee405af7f2048a818ed3f03bbf83c7b # v2.5.0
      with:
        files: |
          score-v1b1.json


================================================
FILE: .gitignore
================================================
**/.DS_Store

================================================
FILE: .lycheeignore
================================================
https://www.bamboohr.com/


================================================
FILE: ADOPTERS.md
================================================
# Score Adopters

This is the list of organizations and users that have publicly shared how they are using Score.

💡 **Want to add your organization? Please [create a PR to add your organization in the list below](https://github.com/score-spec/spec/edit/main/ADOPTERS.md).**

_Note: There are several other organizations and users that are unable to publicly share their stories yet but are active in the Score community. We appreciate all our users and their contributions to make Score a successful CNCF project._

The list of organizations that have publicly shared the usage of Score:

| Organization                        | Success Story |
|:------------------------------------|---------------|
| [BambooHR](https://www.bamboohr.com) | Abstract complex and growing infrastructure while keeping software engineers focused on their strengths with the Score `spec` and the Humanitec Score implementation (`humctl`). |
| [Bechtle](https://www.bechtle.com) | Empower both internal and external Developers to use the Score `spec` to define the containerized workloads and their dependencies, and deploy them to Bechtle's IDP via the Humanitec Score implementation (`humctl`). |
| [Cimpress](https://cimpress.com)   | Provide developers with a code-based, self-service interface to define dependencies for their workloads with the Score `spec`. Simplify the interactions with infrastructure by abstracting the underlying tooling and complexity, reducing cognitive load with the Humanitec Score implementation (`humctl`). |
| [Convera](https://convera.com)     | Enable Developers to choose their preferred level of abstractions for optimal developer self-service and productivity by using the Score `spec` for all their microservices, and deploy them via the Humanitec Score implementation (`humctl`). |
| [Humanitec](https://humanitec.com)  | Use the Score `spec` to define all the containerized workloads and their dependencies of the SaaS product. [`score-compose`](https://docs.score.dev/docs/score-implementation/score-compose/) is used to run integration tests locally and in the CI pipelines with Docker Compose. Score files are deployed via the Humanitec Score implementation (`humctl`). |
| [Mobicom](https://www.mobicom.mn)  | Enable Developers to innovate faster while abstracting operational consistency. Deploy to production now follows a seamless pipeline by using the Score `spec` for all their microservices, and the Humanitec Score implementation (`humctl`). |
<!-- append the line below to the table
| [name](URL) | brief description of how you are using Score |
-->


================================================
FILE: CODEOWNERS
================================================
# This file provides an overview of code owners in this repository.

# Each line is a file pattern followed by one or more owners.
# The last matching pattern has the most precedence.
# For more details, read the following article on GitHub: https://help.github.com/articles/about-codeowners/.

# The default owners are automatically added as reviewers when you open a pull request unless different owners are specified in the file.
* @core-reviewers


================================================
FILE: CODE_OF_CONDUCT.md
================================================
# Code of Conduct

Score follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).


================================================
FILE: CONTRIBUTING.md
================================================
# Contributor guidelines

We are excited that you're interested in contributing to our project! Your efforts help us improve and grow.

## Code of conduct

This project adheres to a [Code of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code. Please report unacceptable behavior to abuse@score.dev.

## Ways to contribute

There are many ways for you to contribute to the Score project, for example:

- **User feedback:** Share your feedback and impressions about the Score specification or any of our reference implementations. Your insights are incredibly helpful for us to further improve and develop the project.

- **Community engagement:** Contribute through speaking engagements, social media, or blog posts.

- **Design:**  Assist with web design to improve our online presence.

- **Documentation:** Help us identify and fix gaps or issues in our developer documentation.

- **Bug reports & fixes:** Encountered a bug or unexpected behavior? Please report it to us, and if possible, contribute a fix.

- **Feature enhancements:** Propose or work on new features for existing Score implementations.

- **Write your own Score implementation:** Score has the potential to integrate with various container orchestration tools such as Google Cloud Run, Azure Container Apps, or HashiCorp Nomad. If you're interested in creating your own Score implementation, we'd love to hear about your plans.

If you're eager to contribute but unsure where to start, reach out to us (e.g., the [Score](https://cloud-native.slack.com/archives/C07DN0D1UCW) channel in the CNCF Slack (<https://slack.cncf.io/>)), and we can explore suitable tasks together.

## Finding an issue

You can discover reported bugs, feature ideas, or discussion topics in the "Issue" section of each repository within the Score organization. Here's where you'll typically find them:

- Spec repository: [This repository](https://github.com/score-spec/spec) contains issues related to the specification or the overall behavior of reference implementations.

- Reference implementation repositories: Repositories like [score-compose](https://github.com/score-spec/score-compose), [score-k8s](https://github.com/score-spec/score-k8s), and [score-helm](https://github.com/score-spec/score-helm) each host issues specific to their respective implementations.

We strive to tag issues with labels such as "good first issue" and "help wanted" to indicate which tasks are up for grabs. If you're having trouble finding a suitable issue, don't worry! As mentioned above, there's likely still an opportunity for you to contribute. Reach out to us, and we'll help you find a task to start with.

## How to get in touch

You can reach us anytime on the [Score](https://cloud-native.slack.com/archives/C07DN0D1UCW) channel in the CNCF Slack (<https://slack.cncf.io/>), where we'll be also be announcing community meetings and events. Additionally, feel free to drop in during our office hours every Thursday between 3-4 pm CET to discuss any issues or questions you have.

## Legal

When contributing to this project, you must agree that you have authored the content, that you have the necessary rights to the content and that the content you contribute may be provided under the [APACHE LICENSE, VERSION 2.0](LICENSE).

### Signoff Your Commits

We kindly ask contributors to sign off on commits submitted to our project's repositories. This sign-off, known as the Developer Certificate of Origin (DCO), verifies that you are the author of the code and have the necessary rights to contribute it. To provide your sign-off, include the following line in your commit messages, ensuring it matches your git user and email:

```bash
This is my commit message

Signed-off-by: Your Name <your.name@example.com>
```

Git has a -s command line option to do this automatically:

``` bash
git commit -s -m 'This is my commit message'
```

If you forgot to do this and have not yet pushed your changes to the remote repository, you can amend your commit with the sign-off by running

``` bash
git commit --amend -s
```

## Example contribution workflow

Here's a quick rundown of how a typical code- or documentation contribution would look like in our project:

1. Find a contribution you would like to make. Learn more about [ways to contribute](#ways-to-contribute).

2. Fork the repository associated with the issue to your local GitHub organization. This means that you will have a copy of the repository under **your-GitHub-username/repository-name**.

3. Clone the repository to your local machine using **git clone**.

4. Create a new branch for your fix using **git checkout -b your-branch-name**.

5. Make the appropriate changes for the issue you are trying to address or the feature that you want to add.

6. Use **git add insert-paths-of-changed-files-here** to add the file contents of the changed files to the "snapshot" git uses to manage the state of the project, also known as the index.

7. Use **git commit -s -m "Insert a brief message of the changes made here"** to store the contents of the index with a descriptive message.

8. Push the changes to the remote repository using **git push origin your-branch-name**.

9. Submit a pull request to the upstream repository.

10. Title the pull request with a brief description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so, "Added more log outputting to resolve #4352".

11. In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It's OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you resolve any problems and improve it.

12. Wait for the pull request to be reviewed by a maintainer.

13. Introduce changes to the pull request if the reviewing maintainer recommends them.

14. Merge your pull request once approved.

15. Celebrate your success after your pull request is merged!

 If you have any questions or need assistance, feel free to reach out to us. We're here to help!


================================================
FILE: GOVERNANCE.md
================================================
# Score Goveranance

This document defines the governance framework for the Score project, encompassing all repositories within the https://github.com/score-spec organization.

All project participants must adhere to our [Code of Conduct](./CODE_OF_CONDUCT.md).

## Maintainers

Maintainers of Score have write access to the project GitHub repositories, allowing them to merge their own contributions and those from others. A list of current maintainers is available in the [MAINTAINERS](./MAINTAINERS.md) file. Collectively, maintainers oversee the project's resources and contributors.

Being a maintainer is a privilege accompanied by responsibilities. Maintainers are expected to demonstrate a strong commitment to the project, collaborate effectively, seek comprehensive reviews for code and documentation, contribute high-quality code, and resolve issues diligently.

## Becoming a Maintainer

To be considered for a maintainer role, a contributor must demonstrate the following:

- Commitment to the project through active participation in discussions, contributions, and reviews for at least six months.
- Conducting reviews for at least 20 non-trivial pull requests.
- Contributing and successfully merging at least 20 non-trivial pull requests.
- The ability to write quality code and/or documentation.
- Effective collaboration with the team.
- A solid understanding of team workflows, including policies, testing processes, and code review procedures.
- Familiarity with the project's codebase and coding and documentation standards.

A new maintainer must be proposed by an existing maintainer and approved through a simple majority vote by the current maintainers.

## Removing a Maintainer

Maintainers may resign at their discretion if they are unable to continue fulfilling their responsibilities.

A maintainer may also be removed due to inactivity, failure to meet responsibilities, violation of the [Code of Conduct](./CODE_OF_CONDUCT.md), or other significant reasons. Inactivity is defined as minimal or no participation in the project for over a year without a planned return to active status.

## Meetings

Where feasible, maintainers are expected to attend public developer meetings and community calls.

Closed meetings will be held to address security issues or Code of Conduct violations. Any maintainer can schedule such a meeting upon receipt of a relevant report. All current maintainers, except those implicated in a Code of Conduct violation, must be invited to these closed meetings.

## Voting

While the majority of project decisions are made through "lazy consensus," there may be instances where maintainers need to vote on specific actions or changes. Votes can be conducted during developer meetings, and any maintainer has the right to request a formal vote.

================================================
FILE: LICENSE
================================================
                                 Apache License
                           Version 2.0, January 2004
                        http://www.apache.org/licenses/

   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION

   1. Definitions.

      "License" shall mean the terms and conditions for use, reproduction,
      and distribution as defined by Sections 1 through 9 of this document.

      "Licensor" shall mean the copyright owner or entity authorized by
      the copyright owner that is granting the License.

      "Legal Entity" shall mean the union of the acting entity and all
      other entities that control, are controlled by, or are under common
      control with that entity. For the purposes of this definition,
      "control" means (i) the power, direct or indirect, to cause the
      direction or management of such entity, whether by contract or
      otherwise, or (ii) ownership of fifty percent (50%) or more of the
      outstanding shares, or (iii) beneficial ownership of such entity.

      "You" (or "Your") shall mean an individual or Legal Entity
      exercising permissions granted by this License.

      "Source" form shall mean the preferred form for making modifications,
      including but not limited to software source code, documentation
      source, and configuration files.

      "Object" form shall mean any form resulting from mechanical
      transformation or translation of a Source form, including but
      not limited to compiled object code, generated documentation,
      and conversions to other media types.

      "Work" shall mean the work of authorship, whether in Source or
      Object form, made available under the License, as indicated by a
      copyright notice that is included in or attached to the work
      (an example is provided in the Appendix below).

      "Derivative Works" shall mean any work, whether in Source or Object
      form, that is based on (or derived from) the Work and for which the
      editorial revisions, annotations, elaborations, or other modifications
      represent, as a whole, an original work of authorship. For the purposes
      of this License, Derivative Works shall not include works that remain
      separable from, or merely link (or bind by name) to the interfaces of,
      the Work and Derivative Works thereof.

      "Contribution" shall mean any work of authorship, including
      the original version of the Work and any modifications or additions
      to that Work or Derivative Works thereof, that is intentionally
      submitted to Licensor for inclusion in the Work by the copyright owner
      or by an individual or Legal Entity authorized to submit on behalf of
      the copyright owner. For the purposes of this definition, "submitted"
      means any form of electronic, verbal, or written communication sent
      to the Licensor or its representatives, including but not limited to
      communication on electronic mailing lists, source code control systems,
      and issue tracking systems that are managed by, or on behalf of, the
      Licensor for the purpose of discussing and improving the Work, but
      excluding communication that is conspicuously marked or otherwise
      designated in writing by the copyright owner as "Not a Contribution."

      "Contributor" shall mean Licensor and any individual or Legal Entity
      on behalf of whom a Contribution has been received by Licensor and
      subsequently incorporated within the Work.

   2. Grant of Copyright License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      copyright license to reproduce, prepare Derivative Works of,
      publicly display, publicly perform, sublicense, and distribute the
      Work and such Derivative Works in Source or Object form.

   3. Grant of Patent License. Subject to the terms and conditions of
      this License, each Contributor hereby grants to You a perpetual,
      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
      (except as stated in this section) patent license to make, have made,
      use, offer to sell, sell, import, and otherwise transfer the Work,
      where such license applies only to those patent claims licensable
      by such Contributor that are necessarily infringed by their
      Contribution(s) alone or by combination of their Contribution(s)
      with the Work to which such Contribution(s) was submitted. If You
      institute patent litigation against any entity (including a
      cross-claim or counterclaim in a lawsuit) alleging that the Work
      or a Contribution incorporated within the Work constitutes direct
      or contributory patent infringement, then any patent licenses
      granted to You under this License for that Work shall terminate
      as of the date such litigation is filed.

   4. Redistribution. You may reproduce and distribute copies of the
      Work or Derivative Works thereof in any medium, with or without
      modifications, and in Source or Object form, provided that You
      meet the following conditions:

      (a) You must give any other recipients of the Work or
          Derivative Works a copy of this License; and

      (b) You must cause any modified files to carry prominent notices
          stating that You changed the files; and

      (c) You must retain, in the Source form of any Derivative Works
          that You distribute, all copyright, patent, trademark, and
          attribution notices from the Source form of the Work,
          excluding those notices that do not pertain to any part of
          the Derivative Works; and

      (d) If the Work includes a "NOTICE" text file as part of its
          distribution, then any Derivative Works that You distribute must
          include a readable copy of the attribution notices contained
          within such NOTICE file, excluding those notices that do not
          pertain to any part of the Derivative Works, in at least one
          of the following places: within a NOTICE text file distributed
          as part of the Derivative Works; within the Source form or
          documentation, if provided along with the Derivative Works; or,
          within a display generated by the Derivative Works, if and
          wherever such third-party notices normally appear. The contents
          of the NOTICE file are for informational purposes only and
          do not modify the License. You may add Your own attribution
          notices within Derivative Works that You distribute, alongside
          or as an addendum to the NOTICE text from the Work, provided
          that such additional attribution notices cannot be construed
          as modifying the License.

      You may add Your own copyright statement to Your modifications and
      may provide additional or different license terms and conditions
      for use, reproduction, or distribution of Your modifications, or
      for any such Derivative Works as a whole, provided Your use,
      reproduction, and distribution of the Work otherwise complies with
      the conditions stated in this License.

   5. Submission of Contributions. Unless You explicitly state otherwise,
      any Contribution intentionally submitted for inclusion in the Work
      by You to the Licensor shall be under the terms and conditions of
      this License, without any additional terms or conditions.
      Notwithstanding the above, nothing herein shall supersede or modify
      the terms of any separate license agreement you may have executed
      with Licensor regarding such Contributions.

   6. Trademarks. This License does not grant permission to use the trade
      names, trademarks, service marks, or product names of the Licensor,
      except as required for reasonable and customary use in describing the
      origin of the Work and reproducing the content of the NOTICE file.

   7. Disclaimer of Warranty. Unless required by applicable law or
      agreed to in writing, Licensor provides the Work (and each
      Contributor provides its Contributions) on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
      implied, including, without limitation, any warranties or conditions
      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
      PARTICULAR PURPOSE. You are solely responsible for determining the
      appropriateness of using or redistributing the Work and assume any
      risks associated with Your exercise of permissions under this License.

   8. Limitation of Liability. In no event and under no legal theory,
      whether in tort (including negligence), contract, or otherwise,
      unless required by applicable law (such as deliberate and grossly
      negligent acts) or agreed to in writing, shall any Contributor be
      liable to You for damages, including any direct, indirect, special,
      incidental, or consequential damages of any character arising as a
      result of this License or out of the use or inability to use the
      Work (including but not limited to damages for loss of goodwill,
      work stoppage, computer failure or malfunction, or any and all
      other commercial damages or losses), even if such Contributor
      has been advised of the possibility of such damages.

   9. Accepting Warranty or Additional Liability. While redistributing
      the Work or Derivative Works thereof, You may choose to offer,
      and charge a fee for, acceptance of support, warranty, indemnity,
      or other liability obligations and/or rights consistent with this
      License. However, in accepting such obligations, You may act only
      on Your own behalf and on Your sole responsibility, not on behalf
      of any other Contributor, and only if You agree to indemnify,
      defend, and hold each Contributor harmless for any liability
      incurred by, or claims asserted against, such Contributor by reason
      of your accepting any such warranty or additional liability.

   END OF TERMS AND CONDITIONS

   APPENDIX: How to apply the Apache License to your work.

      To apply the Apache License to your work, attach the following
      boilerplate notice, with the fields enclosed by brackets "[]"
      replaced with your own identifying information. (Don't include
      the brackets!)  The text should be enclosed in the appropriate
      comment syntax for the file format. We also recommend that a
      file or class name and description of purpose be included on the
      same "printed page" as the copyright notice for easier
      identification within third-party archives.

   Copyright 2022 The Score Authors.

   Licensed 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.


================================================
FILE: MAINTAINERS.md
================================================
# Score maintainers

The following is the list of maintainers for all Score repositories, in alphabetical order:

- Ben Meier (Oracle) [@astromechza](https://github.com/astromechza)
- Chris Stephenson (Independent) [@chris-stephenson](https://github.com/chris-stephenson)
- Mathieu Benoit (Docker) [@mathieu-benoit](https://github.com/mathieu-benoit)
- Susa Tünker (Checkly) [@sujaya-sys](https://github.com/sujaya-sys)


================================================
FILE: Makefile
================================================
# Disable all the default make stuff
MAKEFLAGS += --no-builtin-rules
.SUFFIXES:

SCORE_EXAMPLES_DIR ?= ./samples

## Display help menu
.PHONY: help
help:
	@echo Documented Make targets:
	@perl -e 'undef $$/; while (<>) { while ($$_ =~ /## (.*?)(?:\n# .*)*\n.PHONY:\s+(\S+).*/mg) { printf "\033[36m%-30s\033[0m %s\n", $$2, $$1 } }' $(MAKEFILE_LIST) | sort

# ------------------------------------------------------------------------------
# NON-PHONY TARGETS
# ------------------------------------------------------------------------------

${GOPATH}/bin/jv:
ifeq ($(GOPATH),)
	$(error GOPATH must be set)
endif
	go install github.com/santhosh-tekuri/jsonschema/cmd/jv@latest

# ------------------------------------------------------------------------------
# PHONY TARGETS
# ------------------------------------------------------------------------------

.PHONY: .ALWAYS
.ALWAYS:

## Test that the score schema matches the json-schema reference
.PHONY: test-schema
test-schema: ${GOPATH}/bin/jv
	${GOPATH}/bin/jv --assert-format --assert-content https://json-schema.org/draft/2020-12/schema ./score-v1b1.json
	@echo "Schema is a valid jsonschema"

## Test that the given score examples in $SCORE_EXAMPLES_DIR match the schema
.PHONY: test-examples
test-examples: ${GOPATH}/bin/jv
ifeq ($(SCORE_EXAMPLES_DIR),)
	$(error SCORE_EXAMPLES_DIR must be set)
endif
	for f in $$(find ${SCORE_EXAMPLES_DIR} -name 'score*.yaml' -print); do ${GOPATH}/bin/jv --assert-format --assert-content ./score-v1b1.json $$f; done
	@echo "Schema matches all samples"

## Run all tests
.PHONY: test
test: test-schema test-examples


================================================
FILE: README.md
================================================
[![License](https://img.shields.io/badge/License-Apache_2.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
[![Contributor Covenant](https://img.shields.io/badge/Contributor%20Covenant-2.1-4baaaa.svg)](CODE_OF_CONDUCT.md)
[![good first issues](https://img.shields.io/github/issues-search/score-spec/spec?query=type%3Aissue%20is%3Aopen%20label%3A%22good%20first%20issue%22&label=good%20first%20issues&style=flat&logo=github)](https://github.com/score-spec/spec/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22)

![Score banner](/docs/images/banner.png)

## ![Score](/docs/images/logo.svg) The Score Specification

Score is an open-source workload specification designed to simplify development for cloud-native developers. The specification enables you to describe your workload's configuration in a vendor-neutral way, eliminating the need for tooling-specific syntax from platforms such as Docker Compose or Kubernetes. By leveraging familiar concepts and semantics, defining a workload’s configuration becomes as simple as stating, “I want a database of type X and an event queue of type Y to accompany my workload”.

Below is an example of a Score specification describing a web server that queries a Postgres database on each request. Typically, this file is saved alongside the workload's source code in version control.

```YAML
# The version string helps identify the Score file syntax
apiVersion: score.dev/v1b1
metadata:
  name: sample

# A set of containers deployed together for this Workload.
containers:
  main:
    # The "default" image for our service. When deploying, we may override this with a particular tag.
    image: ghcr.io/score-spec/sample-app-gif:sha-2533037
    variables:
      # Pass the resource outputs to our container as environment variables. The Score implementation takes care of securing any secret access as needed.
      PG_CONNECTION_STRING: "postgresql://${resources.db.username}:${resources.db.password}@${resources.db.host}:${resources.db.port}/${resources.db.database}?sslmode=disable"

# The service ports indicate which ports of the Workload are exposed for other services to call.
service:
  ports:
    web:
      port: 8080

# Each resource dependency has a name and definition that helps the Score implementation link or provision the required resource.
resources:
  db:
    # This database is specific to this Workload and not shared.
    type: postgres
  dns:
    # Ensure a dns name is available for request routing.
    type: dns
  route:
    # We want to ensure that requests on the Workload hostname go to our service port.
    type: route
    params:
      host: ${resources.dns.host}
      path: /
      port: 8080
```

### Key Features of Score

Looking at the example above, you'll notice that the Score specification is:

* **platform-agnostic**: Score is not tied to any specific platform or tool. It integrates seamlessly with Docker, Kubernetes, Helm, and other container orchestration platforms, allowing developers to define the Score spec once, independently of the target environments.

* **environment-agnostic**: Score captures the configuration that remains consistent across all environments, effectively separating environment-agnostic from environment-specific configurations. For instance, the database connection string `PG_CONNECTION_STRING` in the example above is parameterized (i.e. described in an environment-agnostic way), allowing it to be resolved in each target environment with the appropriate credentials.

* **tightly scoped**: Score describes workload-level properties. It does not intend to be a fully featured YAML replacement for any platform, thereby shielding developers from the complexity of container orchestration tools like Kubernetes.

* **declarative**: With Score, developers declare what their workload requires to run as part of the Score specification. The platform in the target environment is responsible for resolving individual runtime requirements. This establishes a contract between dev and ops: If the requirements listed in the spec are honoured, the workload will run as intended.

The current version of the specification schema is stored [here](./score-v1b1.json). For a more detailed specification reference, check out our [developer documentation](https://docs.score.dev/docs/score-specification/score-spec-reference/).

## ![Score](/docs/images/logo.svg) Implementation of the Score Specification

Once you define your workload's runtime requirements with the Score specification, a Score Implementation translates it into the desired target output format as illustrated in the graphic below.

![how-score-works](/docs/images/how-score-works.png)

Currently, we offer two reference implementations:

* [score-compose](https://github.com/score-spec/score-compose): Converts your Score specification into a `docker-compose.yaml` file.
* [score-k8s](https://github.com/score-spec/score-k8s): Generates `manifests.yaml` files from your Score specification to deploy to a Kubernetes cluster.

These implementations are suitable for practical use and serve as blueprints for creating custom implementations. If you're interested in building a Score implementation but need guidance, feel free to reach out — we're here to help!

Community-built implementations are typically hosted and maintained by their creators. These can be referenced in our documentation or kept private. If a contributor wishes to donate their implementation to our project, we are open to exploring that option.

## ![Score](/docs/images/logo.svg) Benefits of Score

Score aims to reduce developer toil and cognitive load by only having to define a single specification file that works across multiple platforms. Cloud native developers often struggle with configuration inconsistencies between environments. This gets even more complicated when the technology stack in each environment is different. For example: What if you use Docker Compose for local development, but deploy to a Kubernetes-based development environment? Not only do you have to figure out Docker Compose and Kubernetes, but you need to keep them in sync. This results in various bottlenecks along the application delivery lifecycle:

- Tech & tools that require specialized knowledge and operational expertise are imposed on developers.

- Different configuration rules, constructs and values between local and remote environments increase the risk of configuration inconsistencies.

- Keeping a multitude of platforms and environment-specific configuration files in sync leads to repetitive configuration work.

Score provides a single, easy to understand specification for each workload that describes its runtime requirements in a declarative manner. The `score.yaml` file allows generating configuration in an automated, standardized and one directional way.

By reducing the risk of incorrect or inconsistent configurations across environments, Score helps developers focus on their core tasks and enhances their day-to-day work experience.

## ![Get in touch](/docs/images/get-involved.svg) Get in touch

Connect with us through the [Score](https://cloud-native.slack.com/archives/C07DN0D1UCW) channel in the CNCF Slack (<https://slack.cncf.io/>) or contact us via email at team@score.dev.

We host regular community meetings to discuss updates, share ideas, and collaborate. Here are the details:

| Community call | Info |
|:-----------|:------------|
| Meeting Link | Join via [Zoom](https://zoom-lfx.platform.linuxfoundation.org/meeting/98284206225?password=a09e77df-8c63-44ca-8a48-12de22fdffe4) or view the [Calendar](https://zoom-lfx.platform.linuxfoundation.org/meetings/score?view=month) |
| Meeting Agenda & Notes | Add to our agenda or review minutes [here](https://github.com/score-spec/spec/discussions/categories/community-meetings) |
| Meeting Time | 3:00-4:00 CET/CEST, every first Thursday of the month unless specified |

If you can't attend at the scheduled time but would like to discuss something, please reach out. We’re happy to arrange an ad-hoc meeting that fits your schedule.

### Documentation

You can find our documentation at [docs.score.dev](https://docs.score.dev/docs/).

### Roadmap

See [Roadmap](roadmap.md). You can [submit an idea](https://github.com/score-spec/spec/issues/new) anytime.

### Contribution Guidelines and Governance

Our general contributor guidelines can be found in [CONTRIBUTING.md](CONTRIBUTING.md). Please note that some repositories may have additional guidelines. For more information on our governance model, please refer to [GOVERNANCE.md](GOVERNANCE.md).


================================================
FILE: SECURITY.md
================================================
# Security Policy

Thank you for taking the time to report a security vulnerability. We would like to investigate every report thoroughly.

## Reporting a Vulnerability

_Note: Please do not open a public issue describing the vulnerability._

To report a security vulnerability, please navigate to the `Security` tab of the associated repository, and click on the [`Report a vulnerability`](https://github.com/score-spec/spec/security/advisories/new) button.

Then, fill in all the details of the vulnerability in English and click on `Submit report`. This submission will only be viewable to repository maintainers and will help us triage your report more quickly.

## Evaluation and Response

Response times could be affected by weekends, holidays, breaks or time zone differences. That said, the maintainers team endeavours to evaluate your report and reply as soon as possible, ideally within 10 working days.


================================================
FILE: roadmap.md
================================================
# Score Roadmap

## Generalized Score extension mechanism

The Score Specification allows developers to define the main characteristics of their Workload. It reduces cognitive load by providing sensible defaults, meaning it only exposes the most important and commonly utilized properties of a Workload's definition. At the same time, should the spec be able to accommodate any additional configuration options that are needed by its users.
The implementation of a generalized extension mechanism allows users to extend their `score.yaml` files with properties that are not included as part of the core Workload specification.

## Score implementation CLIs

As a platform-agnostic Workload specification, the Score Spec integrates with many container orchestration platforms. To expose its full potential, additional implementations for popular tooling such as Kustomize, Amazon ECS, Google Cloud Run, or Nomad are needed.
This would allow an increasing amount of users to integrate Score into their existing tech stack, or migrate to a different tech stack without additional engineering effort.

## Score Developer Documentation

The developer documentation [docs.score.dev](https://docs.score.dev/docs/) plays a crucial role in onboarding new users to Score and supporting them in their day-to-day usage.
To be helpful for users of all experiences and for a variety of use cases, additional documentation in the form of real-world usage examples, tutorials, demos, and educational material on underlying concepts such as containers, container orchestration platforms, CLI tooling and similar is needed.
With this, a smooth onboarding experience that defines clear learning paths forward can be provided for Score's users.

# Get involved

You can start a discussion or submit an idea [here](https://github.com/score-spec/spec/issues/new) anytime.


================================================
FILE: samples/score-deprecated-files-and-volumes.yaml
================================================
# The following workload describes a container which has a file and volume mounted. The file mount is using the deprecated format of an array of files.
# This was deprecated since files do not infer order and the "target" path can be considered both required and unique. Simalarly, the volume mount is also
# using a deprecated array format.
# ==========================================================================================================================================
apiVersion: score.dev/v1b1
metadata:
  name: "deprecated-files-example"
containers:
  main:
    image: "example-image:latest"
    files:
    - target: /mnt/some-path
      content: "my content here"
    volumes:
    - target: /mnt/vol
      source: some-volume


================================================
FILE: samples/score-full.yaml
================================================
apiVersion: score.dev/v1b1
metadata:
  name: example-workload-name123
  extra-key: extra-value
  annotations:
    prefix.com/Another-Key_Annotation.2: something else
service:
  ports:
    port-one:
      port: 1000
      protocol: TCP
      targetPort: 10000
    port-two2:
      port: 8000
containers:
  container-one1:
    image: localhost:4000/repo/my-image:tag
    command: ["/bin/sh", "-c"]
    args: ["hello", "world"]
    resources:
      requests:
        cpu: 1000m
        memory: 10Gi
      limits:
        cpu: "0.24"
        memory: 128M
    variables:
      SOME_VAR: some content here
    files:
      /my/file:
        mode: "0600"
        source: file.txt
      /my/other/file:
        content: |
          some multiline
          content
      /my/other/binaryfile:
        binaryContent: ADBgwpA=
    volumes:
      /mnt/something:
        source: volume-name
        path: /sub/path
        readOnly: false
      /mnt/something-else:
        source: volume-two
    livenessProbe:
      httpGet:
        port: 8080
        path: /livez
      exec:
        command:
        - /bin/curl
        - -f
        - "http://localhost:8080/livez"
    readinessProbe:
      httpGet:
        host: 127.0.0.1
        port: 80
        scheme: HTTP
        path: /readyz
        httpHeaders:
        - name: SOME_HEADER
          value: some-value-here
  container-two2:
    image: .
resources:
  resource-one1:
    metadata:
      annotations:
        Default-Annotation: this is my annotation
        prefix.com/Another-Key_Annotation.2: something else
      extra-key: extra-value
    type: Resource-One
    class: default
    params:
      extra:
        data: here
  resource-two2:
    type: Resource-Two
  resource-three:
    type: Type-Three
    id: shared-type-three


================================================
FILE: score-v1b1.json
================================================
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://score.dev/schemas/score",
  "title": "Score schema",
  "description": "Score workload specification",
  "type": "object",
  "required": [
    "apiVersion",
    "metadata",
    "containers"
  ],
  "additionalProperties": false,
  "properties": {
    "apiVersion": {
      "description": "The declared Score Specification version.",
      "type": "string",
      "pattern": "^score\\.dev/v1b1$"
    },
    "metadata": {
      "description": "The metadata description of the Workload.",
      "type": "object",
      "required": [
        "name"
      ],
      "additionalProperties": true,
      "properties": {
        "name": {
          "description": "A string that can describe the Workload. This must be a valid RFC1123 Label Name of up to 63 characters, including a-z, 0-9, '-' but may not start or end with '-'.",
          "type": "string",
          "minLength": 2,
          "maxLength": 63,
          "pattern": "^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$"
        },
        "annotations": {
          "description": "Annotations that apply to the Workload. The annotation can contain A-Z, a-z, 0-9, and '-' and may contain an optional /-separated RFC1123 Host Name prefix.",
          "type": "object",
          "additionalProperties": {
            "type": "string"
          },
          "propertyNames": {
            "minLength": 2,
            "maxLength": 316,
            "pattern": "^(([a-z0-9][a-z0-9-]{0,61}[a-z0-9])(\\.[a-z0-9][a-z0-9-]{0,61}[a-z0-9])*/)?[A-Za-z0-9][A-Za-z0-9._-]{0,61}[A-Za-z0-9]$"
          }
        }
      }
    },
    "service": {
      "description": "The service that the workload provides.",
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "ports": {
          "description": "The set of named network ports published by the service. The service name must be a valid RFC1123 Label Name of up to 63 characters, including a-z, 0-9, '-' but may not start or end with '-'.",
          "type": "object",
          "propertyNames": {
            "minLength": 2,
            "maxLength": 63,
            "pattern": "^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$"
          },
          "additionalProperties": {
            "$ref": "#/$defs/servicePort"
          }
        }
      }
    },
    "containers": {
      "description": "The set of named containers in the Workload. The container name must be a valid RFC1123 Label Name of up to 63 characters, including a-z, 0-9, '-' but may not start or end with '-'.",
      "type": "object",
      "minProperties": 1,
      "additionalProperties": {
        "$ref": "#/$defs/container"
      },
      "propertyNames": {
        "minLength": 2,
        "maxLength": 63,
        "pattern": "^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$"
      }
    },
    "resources": {
      "description": "The Resource dependencies needed by the Workload. The resource name must be a valid RFC1123 Label Name of up to 63 characters, including a-z, 0-9, '-' but may not start or end with '-'.",
      "type": "object",
      "additionalProperties": {
        "$ref": "#/$defs/resource"
      },
      "propertyNames": {
        "minLength": 2,
        "maxLength": 63,
        "pattern": "^[a-z0-9][a-z0-9-]{0,61}[a-z0-9]$"
      }
    }
  },
  "$defs": {
    "servicePort": {
      "description": "The network port description.",
      "type": "object",
      "required": [
        "port"
      ],
      "additionalProperties": false,
      "properties": {
        "port": {
          "description": "The public service port.",
          "type": "integer",
          "minimum": 1,
          "maximum": 65535
        },
        "protocol": {
          "description": "The transport level protocol. Defaults to TCP.",
          "type": "string",
          "enum": [
            "TCP",
            "UDP"
          ]
        },
        "targetPort": {
          "description": "The internal service port. This will default to 'port' if not provided.",
          "type": "integer",
          "minimum": 1,
          "maximum": 65535
        }
      }
    },
    "resource": {
      "description": "The set of Resources associated with this Workload.",
      "type": "object",
      "additionalProperties": false,
      "required": [
        "type"
      ],
      "properties": {
        "type": {
          "description": "The Resource type. This should be a type supported by the Score implementations being used.",
          "type": "string",
          "minLength": 2,
          "maxLength": 63,
          "pattern": "^[A-Za-z0-9][A-Za-z0-9-]{0,61}[A-Za-z0-9]$"
        },
        "class": {
          "description": "An optional specialisation of the Resource type.",
          "type": "string",
          "minLength": 2,
          "maxLength": 63,
          "pattern": "^[A-Za-z0-9][A-Za-z0-9-]{0,61}[A-Za-z0-9]$"
        },
        "id": {
          "description": "An optional Resource identifier. The id may be up to 63 characters, including one or more labels of a-z, 0-9, '-' not starting or ending with '-' separated by '.'. When two resources share the same type, class, and id, they are considered the same resource when used across related Workloads.",
          "type": "string",
          "minLength": 2,
          "maxLength": 63,
          "pattern": "^[a-z0-9]+(?:-+[a-z0-9]+)*(?:\\.[a-z0-9]+(?:-+[a-z0-9]+)*)*$"
        },
        "metadata": {
          "description": "The metadata for the Resource.",
          "type": "object",
          "additionalProperties": true,
          "properties": {
            "annotations": {
              "description": "Annotations that apply to the Resource. The annotation can contain A-Z, a-z, 0-9, and '-' and may contain an optional /-separated RFC1123 Host Name prefix.",
              "type": "object",
              "additionalProperties": {
                "type": "string"
              },
              "propertyNames": {
                "minLength": 2,
                "maxLength": 316,
                "pattern": "^(([a-z0-9][a-z0-9-]{0,61}[a-z0-9])(\\.[a-z0-9][a-z0-9-]{0,61}[a-z0-9])*/)?[A-Za-z0-9][A-Za-z0-9._-]{0,61}[A-Za-z0-9]$"
              }
            }
          }
        },
        "params": {
          "description": "Optional parameters used to provision the Resource in the environment.",
          "type": "object",
          "additionalProperties": true
        }
      }
    },
    "resourcesLimits": {
      "description": "The compute and memory resource limits.",
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "memory": {
          "description": "The memory limit in bytes with optional unit specifier. For example 125M or 1Gi.",
          "type": "string",
          "pattern": "^[1-9]\\d*(K|M|G|T|Ki|Mi|Gi|Ti)?$"
        },
        "cpu": {
          "description": "The CPU limit as whole or fractional CPUs. 'm' indicates milli-CPUs. For example 2 or 125m.",
          "type": "string",
          "pattern": "^\\d*(?:m|\\.\\d+)?$"
        }
      }
    },
    "containerFile": {
      "description": "The details of a file to mount in the container. One of 'source', 'content', or 'binaryContent' must be provided.",
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "target": {
          "description": "(Deprecated) The file path to expose in the container. This is only used in Score workloads that describe files as an array.",
          "deprecated": true,
          "type": "string",
          "minLength": 1
        },
        "mode": {
          "description": "The optional file access mode in octal encoding. For example 0600.",
          "type": "string",
          "pattern": "^0?[0-7]{3}$"
        },
        "source": {
          "description": "The relative or absolute path to the content file.",
          "type": "string",
          "minLength": 1
        },
        "content": {
          "description": "The inline content for the file. Only supports valid utf-8.",
          "type": "string"
        },
        "binaryContent": {
          "description": "Inline standard-base64 encoded content for the file. Does not support placeholder expansion.",
          "type": "string"
        },
        "noExpand": {
          "description": "If set to true, the placeholders expansion will not occur in the contents of the file.",
          "type": "boolean"
        }
      },
      "oneOf": [
        {
          "required": [
            "content"
          ]
        },
        {
          "required": [
            "binaryContent"
          ]
        },
        {
          "required": [
            "source"
          ]
        }
      ]
    },
    "containerVolume": {
      "type": "object",
      "additionalProperties": false,
      "required": [
        "source"
      ],
      "properties": {
        "source": {
          "description": "The external volume reference.",
          "type": "string"
        },
        "path": {
          "description": "An optional sub path in the volume.",
          "type": "string"
        },
        "target": {
          "description": "(Deprecated) The target mount on the container. This is only used in Score workloads that describe volumes as an array.",
          "deprecated": true,
          "type": "string"
        },
        "readOnly": {
          "description": "Indicates if the volume should be mounted in a read-only mode.",
          "type": "boolean"
        }
      }
    },
    "container": {
      "description": "The specification of a Container within the Workload.",
      "type": "object",
      "required": [
        "image"
      ],
      "additionalProperties": false,
      "properties": {
        "image": {
          "description": "The container image name and tag.",
          "type": "string",
          "minLength": 1
        },
        "command": {
          "description": "If specified, overrides the entrypoint defined in the container image.",
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "args": {
          "description": "If specified, overrides the arguments passed to the container entrypoint.",
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "variables": {
          "description": "The environment variables for the container.",
          "type": "object",
          "propertyNames": {
            "minLength": 1,
            "pattern": "^[^=]+$"
          },
          "additionalProperties": {
            "type": "string"
          }
        },
        "files": {
          "description": "The extra files to mount into the container. Described as a map of target paths to file details. The array form is deprecated.", 
          "oneOf": [
            {
              "type": "array",
              "deprecated": true,
              "items": {
                "$ref": "#/$defs/containerFile"
              }
            },
            {
              "type": "object",
              "additionalProperties": {
                "allOf": [
                  {
                    "not": {
                      "type": "object",
                      "additionalProperties": true,
                      "required": ["target"]
                    }
                  },
                  {
                    "$ref": "#/$defs/containerFile"
                  }
                ]
              }
            }
          ]
        },
        "volumes": {
          "description": "The volumes to mount. Described as a map of target paths to volume details. The array form is deprecated.",
          "oneOf": [
            {
              "type": "array",
              "deprecated": true,
              "items": {
                "$ref": "#/$defs/containerVolume"
              }
            },
            {
              "type": "object",
              "additionalProperties": {
                "allOf": [
                  {
                    "not": {
                      "type": "object",
                      "additionalProperties": true,
                      "required": ["target"]
                    }
                  },
                  {
                    "$ref": "#/$defs/containerVolume"
                  }
                ]
              }
            }
          ]
        },
        "resources": {
          "description": "The compute resources for the container.",
          "type": "object",
          "additionalProperties": false,
          "properties": {
            "limits": {
              "description": "The maximum allowed resources for the container.",
              "$ref": "#/$defs/resourcesLimits"
            },
            "requests": {
              "description": "The minimal resources required for the container.",
              "$ref": "#/$defs/resourcesLimits"
            }
          }
        },
        "livenessProbe": {
          "description": "The liveness probe for the container.",
          "$ref": "#/$defs/containerProbe"
        },
        "readinessProbe": {
          "description": "The readiness probe for the container.",
          "$ref": "#/$defs/containerProbe"
        }
      }
    },
    "containerProbe": {
      "type": "object",
      "description": "The probe may be defined as either http, command execution, or both. The execProbe should be preferred if the Score implementation supports both types.",
      "additionalProperties": false,
      "properties": {
        "httpGet": {
          "$ref": "#/$defs/httpProbe"
        },
        "exec": {
          "$ref": "#/$defs/execProbe"
        }
      }
    },
    "execProbe": {
      "description": "An executable health probe.",
      "type": "object",
      "additionalProperties": false,
      "required": ["command"],
      "properties": {
        "command": {
          "description": "The command and arguments to execute within the container.",
          "type": "array",
          "items": {
            "type": "string"
          }
        }
      }
    },
    "httpProbe": {
      "description": "An HTTP probe details.",
      "type": "object",
      "additionalProperties": false,
      "required": [
        "port",
        "path"
      ],
      "properties": {
        "host": {
          "description": "Host name to connect to. Defaults to the workload IP. The is equivalent to a Host HTTP header.",
          "type": "string",
          "minLength": 1
        },
        "scheme": {
          "description": "Scheme to use for connecting to the host (HTTP or HTTPS). Defaults to HTTP.",
          "type": "string",
          "enum": [
            "HTTP",
            "HTTPS"
          ]
        },
        "path": {
          "description": "The path to access on the HTTP server.",
          "type": "string"
        },
        "port": {
          "description": "The port to access on the workload.",
          "type": "integer",
          "minimum": 1,
          "maximum": 65535
        },
        "httpHeaders": {
          "description": "Additional HTTP headers to send with the request",
          "type": "array",
          "items": {
            "type": "object",
            "additionalProperties": false,
            "required": [
              "name",
              "value"
            ],
            "properties": {
              "name": {
                "description": "The HTTP header name.",
                "type": "string",
                "pattern": "^[A-Za-z0-9_-]+$"
              },
              "value": {
                "description": "The HTTP header value.",
                "type": "string",
                "minLength": 1
              }
            }
          }
        }
      }
    }
  }
}