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] " 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 } } } } } } } }