├── .github ├── ISSUE_TEMPLATE │ ├── config.yml │ ├── FEATURE_REQUEST.md │ └── BUG.md └── PULL_REQUEST_TEMPLATE │ └── PULL_REQUEST.md ├── .gitignore ├── .yamllint ├── src ├── scripts │ ├── greet.sh │ └── README.md ├── executors │ ├── default.yml │ └── README.md ├── jobs │ ├── hello.yml │ └── README.md ├── examples │ ├── example.yml │ └── README.md ├── tests │ ├── greet.bats │ └── README.md ├── commands │ ├── greet.yml │ └── README.md ├── @orb.yml └── README.md ├── CHANGELOG.md ├── LICENSE ├── .circleci ├── README.md └── config.yml └── README.md /.github/ISSUE_TEMPLATE/config.yml: -------------------------------------------------------------------------------- 1 | blank_issues_enabled: false 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # orb.yml is "packed" from source, and not published directly from the repository. 2 | orb.yml -------------------------------------------------------------------------------- /.yamllint: -------------------------------------------------------------------------------- 1 | extends: relaxed 2 | 3 | rules: 4 | line-length: 5 | max: 200 6 | allow-non-breakable-inline-mappings: true 7 | 8 | -------------------------------------------------------------------------------- /src/scripts/greet.sh: -------------------------------------------------------------------------------- 1 | Greet() { 2 | echo Hello "${PARAM_TO}" 3 | } 4 | 5 | # Will not run if sourced for bats-core tests. 6 | # View src/tests for more information. 7 | ORB_TEST_ENV="bats-core" 8 | if [ "${0#*$ORB_TEST_ENV}" == "$0" ]; then 9 | Greet 10 | fi 11 | -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/FEATURE_REQUEST.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\U0001F680 Feature Request" 3 | about: Propose changes to the orb. 4 | title: '' 5 | labels: feature_request 6 | assignees: '' 7 | --- 8 | 9 | ## Describe Request: 10 | 11 | ## Examples: 12 | 13 | ## Supporting Documentation Links: 14 | 15 | -------------------------------------------------------------------------------- /src/executors/default.yml: -------------------------------------------------------------------------------- 1 | description: > 2 | This is a sample executor using Docker and Node. 3 | docker: 4 | - image: 'cimg/node:<>' 5 | parameters: 6 | tag: 7 | default: lts 8 | description: > 9 | Pick a specific cimg/node image variant: 10 | https://hub.docker.com/r/cimg/node/tags 11 | type: string 12 | -------------------------------------------------------------------------------- /src/jobs/hello.yml: -------------------------------------------------------------------------------- 1 | description: > 2 | Sample description 3 | # What will this job do? 4 | # Descriptions should be short, simple, and clear. 5 | 6 | executor: default 7 | 8 | parameters: 9 | to: 10 | type: string 11 | default: "World" 12 | description: "Hello to whom?" 13 | steps: 14 | - greet: 15 | to: << parameters.to >> 16 | -------------------------------------------------------------------------------- /src/examples/example.yml: -------------------------------------------------------------------------------- 1 | description: > 2 | Sample example description. 3 | # Provide a use-case based example for using this orb. 4 | # Everything in the `usage` section will be displayed in the orb registry. 5 | # Comments are not retained. 6 | usage: 7 | version: 2.1 8 | orbs: 9 | : /@1.2.3 10 | workflows: 11 | use-my-orb: 12 | jobs: 13 | - / 14 | -------------------------------------------------------------------------------- /src/tests/greet.bats: -------------------------------------------------------------------------------- 1 | # Runs prior to every test 2 | setup() { 3 | # Load our script file. 4 | source ./src/scripts/greet.sh 5 | } 6 | 7 | @test '1: Greet the world' { 8 | # Mock environment variables or functions by exporting them (after the script has been sourced) 9 | export PARAM_TO="World" 10 | # Capture the output of our "Greet" function 11 | result=$(Greet) 12 | [ "$result" == "Hello World" ] 13 | } -------------------------------------------------------------------------------- /src/commands/greet.yml: -------------------------------------------------------------------------------- 1 | description: > 2 | This command echos "Hello World" using file inclusion. 3 | # What will this command do? 4 | # Descriptions should be short, simple, and clear. 5 | parameters: 6 | to: 7 | type: string 8 | default: "World" 9 | description: "Hello to whom?" 10 | steps: 11 | - run: 12 | environment: 13 | PARAM_TO: <> 14 | name: Hello Greeting 15 | command: <> 16 | -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | All notable changes to this project will be documented in this file. 3 | 4 | The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), 5 | and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). 6 | 7 | ## [Unreleased] 8 | - Current development changes [ to be moved to release ] 9 | 10 | ## [1.0.0] - YYYY-MM-DD 11 | ### Added 12 | - Initial Release 13 | ### Changed 14 | - Initial Release 15 | ### Removed 16 | - Initial Release 17 | 18 | 19 | [1.0.0]: GITHUB TAG URL 20 | -------------------------------------------------------------------------------- /src/@orb.yml: -------------------------------------------------------------------------------- 1 | version: 2.1 2 | 3 | description: > 4 | Sample orb description 5 | # What will your orb allow users to accomplish? 6 | # Descriptions should be short, simple, and informative. 7 | 8 | # This information will be displayed in the orb registry and is not mandatory. 9 | display: 10 | home_url: "https://www.website.com/docs" 11 | source_url: "https://www.github.com/EXAMPLE_ORG/EXAMPLE_PROJECT" 12 | 13 | # If your orb requires other orbs, you can import them like this. Otherwise remove the "orbs" stanza. 14 | # orbs: 15 | # hello: circleci/hello-build@0.0.5 16 | -------------------------------------------------------------------------------- /src/examples/README.md: -------------------------------------------------------------------------------- 1 | # Usage Examples 2 | 3 | Easily author and add [Usage Examples](https://circleci.com/docs/2.0/orb-author/#providing-usage-examples-of-orbs) to the `src/examples` directory. 4 | 5 | Each _YAML_ file within this directory will be treated as an orb usage example, with a name which matches its filename. 6 | 7 | View the included _[example.yml](./example.yml)_ example. 8 | 9 | Usage examples should contain clear use-case based example configurations for using the orb. 10 | 11 | 12 | ## See: 13 | - [Providing Usage examples](https://circleci.com/docs/2.0/orb-author/#providing-usage-examples-of-orbs) -------------------------------------------------------------------------------- /.github/ISSUE_TEMPLATE/BUG.md: -------------------------------------------------------------------------------- 1 | --- 2 | name: "\U0001F41E Bug report" 3 | about: Report any bugs encountered while using this orb. 4 | title: '' 5 | labels: bug 6 | assignees: '' 7 | 8 | --- 9 | 10 | ## Orb version: 11 | 12 | 19 | 20 | ## What happened: 21 | 22 | 26 | 27 | ## Expected behavior: 28 | 29 | 30 | 31 | ## Additional Information: 32 | 33 | -------------------------------------------------------------------------------- /.github/PULL_REQUEST_TEMPLATE/PULL_REQUEST.md: -------------------------------------------------------------------------------- 1 | 2 | **SEMVER Update Type:** 3 | - [ ] Major 4 | - [ ] Minor 5 | - [ ] Patch 6 | 7 | ## Description: 8 | 9 | 13 | 14 | ## Motivation: 15 | 16 | 19 | 20 | **Closes Issues:** 21 | - ISSUE URL 22 | 23 | ## Checklist: 24 | 25 | 30 | 31 | - [ ] All new jobs, commands, executors, parameters have descriptions. 32 | - [ ] Usage Example version numbers have been updated. 33 | - [ ] Changelog has been updated. -------------------------------------------------------------------------------- /src/commands/README.md: -------------------------------------------------------------------------------- 1 | # Commands 2 | 3 | Easily add and author [Reusable Commands](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-commands) to the `src/commands` directory. 4 | 5 | Each _YAML_ file within this directory will be treated as an orb command, with a name which matches its filename. 6 | 7 | View the included _[greet.yml](./greet.yml)_ example. 8 | 9 | ```yaml 10 | description: > 11 | Replace this text with a description for this command. 12 | # What will this command do? 13 | # Descriptions should be short, simple, and clear. 14 | parameters: 15 | greeting: 16 | type: string 17 | default: "Hello" 18 | description: "Select a proper greeting" 19 | steps: 20 | - run: 21 | name: Hello World 22 | command: echo << parameters.greeting >> world 23 | ``` 24 | 25 | ## See: 26 | - [Orb Author Intro](https://circleci.com/docs/2.0/orb-author-intro/#section=configuration) 27 | - [How to author commands](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-commands) 28 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /src/jobs/README.md: -------------------------------------------------------------------------------- 1 | # Jobs 2 | 3 | Easily author and add [Parameterized Jobs](https://circleci.com/docs/2.0/reusing-config/#authoring-parameterized-jobs) to the `src/jobs` directory. 4 | 5 | Each _YAML_ file within this directory will be treated as an orb job, with a name which matches its filename. 6 | 7 | Jobs may invoke orb commands and other steps to fully automate tasks with minimal user configuration. 8 | 9 | View the included _[hello.yml](./hello.yml)_ example. 10 | 11 | 12 | ```yaml 13 | # What will this job do? 14 | # Descriptions should be short, simple, and clear. 15 | Sample description 16 | executor: default 17 | parameters: 18 | greeting: 19 | type: string 20 | default: "Hello" 21 | description: "Select a proper greeting" 22 | steps: 23 | - greet: 24 | greeting: << parameters.greeting >> 25 | ``` 26 | 27 | ## See: 28 | - [Orb Author Intro](https://circleci.com/docs/2.0/orb-author-intro/#section=configuration) 29 | - [How To Author Commands](https://circleci.com/docs/2.0/reusing-config/#authoring-parameterized-jobs) 30 | - [Node Orb "test" Job](https://github.com/CircleCI-Public/node-orb/blob/master/src/jobs/test.yml) -------------------------------------------------------------------------------- /src/README.md: -------------------------------------------------------------------------------- 1 | # Orb Source 2 | 3 | Orbs are shipped as individual `orb.yml` files, however, to make development easier, it is possible to author an orb in _unpacked_ form, which can be _packed_ with the CircleCI CLI and published. 4 | 5 | The default `.circleci/config.yml` file contains the configuration code needed to automatically pack, test, and deploy and changes made to the contents of the orb source in this directory. 6 | 7 | ## @orb.yml 8 | 9 | This is the entry point for our orb "tree", which becomes our `orb.yml` file later. 10 | 11 | Within the `@orb.yml` we generally specify 4 configuration keys 12 | 13 | **Keys** 14 | 15 | 1. **version** 16 | Specify version 2.1 for orb-compatible configuration `version: 2.1` 17 | 2. **description** 18 | Give your orb a description. Shown within the CLI and orb registry 19 | 3. **display** 20 | Specify the `home_url` referencing documentation or product URL, and `source_url` linking to the orb's source repository. 21 | 4. **orbs** 22 | (optional) Some orbs may depend on other orbs. Import them here. 23 | 24 | ## See: 25 | - [Orb Author Intro](https://circleci.com/docs/2.0/orb-author-intro/#section=configuration) 26 | - [Reusable Configuration](https://circleci.com/docs/2.0/reusing-config) -------------------------------------------------------------------------------- /src/executors/README.md: -------------------------------------------------------------------------------- 1 | # Executors 2 | 3 | Easily author and add [Parameterized Executors](https://circleci.com/docs/2.0/reusing-config/#executors) to the `src/executors` directory. 4 | 5 | Each _YAML_ file within this directory will be treated as an orb executor, with a name which matches its filename. 6 | 7 | Executors can be used to parameterize the same environment across many jobs. Orbs nor jobs _require_ executors, but may be helpful in some cases, such as: [parameterizing the Node version for a testing job so that matrix testing may be used](https://circleci.com/orbs/registry/orb/circleci/node#usage-run_matrix_testing). 8 | 9 | View the included _[default.yml](./default.yml)_ example. 10 | 11 | 12 | ```yaml 13 | description: > 14 | This is a sample executor using Docker and Node. 15 | docker: 16 | - image: 'cimg/node:<>' 17 | parameters: 18 | tag: 19 | default: lts 20 | description: > 21 | Pick a specific circleci/node image variant: 22 | https://hub.docker.com/r/cimg/node/tags 23 | type: string 24 | ``` 25 | 26 | ## See: 27 | - [Orb Author Intro](https://circleci.com/docs/2.0/orb-author-intro/#section=configuration) 28 | - [How To Author Executors](https://circleci.com/docs/2.0/reusing-config/#authoring-reusable-executors) 29 | - [Node Orb Executor](https://github.com/CircleCI-Public/node-orb/blob/master/src/executors/default.yml) 30 | -------------------------------------------------------------------------------- /src/scripts/README.md: -------------------------------------------------------------------------------- 1 | # scripts/ 2 | 3 | This is where any scripts you wish to include in your orb can be kept. This is encouraged to ensure your orb can have all aspects tested, and is easier to author, since we sacrifice most features an editor offers when editing scripts as text in YAML. 4 | 5 | As a part of keeping things seperate, it is encouraged to use environment variables to pass through parameters, rather than using the `<< parameter. >>` syntax that CircleCI offers. 6 | 7 | # Including Scripts 8 | 9 | Utilizing the `circleci orb pack` CLI command, it is possible to import files (such as _shell scripts_), using the `<>` syntax in place of any config key's value. 10 | 11 | ```yaml 12 | # commands/greet.yml 13 | description: > 14 | This command echos "Hello World" using file inclusion. 15 | parameters: 16 | to: 17 | type: string 18 | default: "World" 19 | description: "Hello to who?" 20 | steps: 21 | - run: 22 | environment: 23 | PARAM_TO: < 24 | name: Hello < 25 | command: <> 26 | 27 | ``` 28 | 29 | ```shell 30 | # scripts/greet.sh 31 | Greet() { 32 | echo Hello ${PARAM_TO} 33 | } 34 | 35 | # Will not run if sourced from another script. This is done so this script may be tested. 36 | # View src/tests for more information. 37 | if [[ "$_" == "$0" ]]; then 38 | Greet 39 | fi 40 | ``` -------------------------------------------------------------------------------- /.circleci/README.md: -------------------------------------------------------------------------------- 1 | # Orb Development Pipeline 2 | 3 | This configuration file uses [orb-tools orb]() version 10 to automatically _pack_, _test_, and _publish_ CircleCI orbs using this project structure. View the comments within the config file for a full break down 4 | 5 | ## Overview: 6 | 7 | **Imported Orbs** 8 | 9 | Both orb-tools and a development version of your orb will be imported into the config. On the first run, a `dev:alpha` development tag _must_ exist on your orb, but will be handled automatically from there on. 10 | 11 | **Jobs** 12 | 13 | In the _jobs_ key, you will define _integration tests_. These jobs will utilize the functionality of your orb at run-time and attempt to validate their usage with live examples. Integration tests can be an excellent way of determining issues with parameters and run-time execution. 14 | 15 | ### Workflows 16 | 17 | There are two workflows which automate the pack, test, and publishing process. 18 | 19 | **test-pack** 20 | 21 | This is the first of the two workflows run. This workflow is responsible for any testing or prepping prior to integration tests. This is where linting occurs, shellchecking, BATS tests, or anything else that can be be tested without the need for further credentials. 22 | 23 | This Workflow will be placed on _hold_ prior to publishing a new development version of the orb (based on this commit), as this step requires access to specific publishing credentials. 24 | 25 | This allows users to fork the orb repository and begin the pipeline, while the code-owners review that the code is safe to test in an environment where publishing keys will be present. 26 | 27 | Once approved, the development version of the orb will publish and the _trigger-integration-tests-workflow_ job will run, kicking off the next workflow 28 | 29 | **integration-test_deploy** 30 | 31 | The second and final workflow is manually triggered by the _trigger-integration-tests-workflow_ job. In this run, the development version of the orb that was just published will be imported, and the integration tests will run. 32 | 33 | When running on the `master` branch (after merging to `master`), the workflow will additionally publish your new production orb. -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Orb Project Template 2 | 6 | 7 | A starter template for orb projects. Build, test, and publish orbs automatically on CircleCI with [Orb-Tools](https://circleci.com/orbs/registry/orb/circleci/orb-tools). 8 | 9 | Additional READMEs are available in each directory. 10 | 11 | **Meta**: This repository is open for contributions! Feel free to open a pull request with your changes. Due to the nature of this repository, it is not built on CircleCI. The Resources and How to Contribute sections relate to an orb created with this template, rather than the template itself. 12 | 13 | ## Resources 14 | 15 | [CircleCI Orb Registry Page](https://circleci.com/orbs/registry/orb//) - The official registry page of this orb for all versions, executors, commands, and jobs described. 16 | [CircleCI Orb Docs](https://circleci.com/docs/2.0/orb-intro/#section=configuration) - Docs for using and creating CircleCI Orbs. 17 | 18 | ### How to Contribute 19 | 20 | We welcome [issues](https://github.com///issues) to and [pull requests](https://github.com///pulls) against this repository! 21 | 22 | ### How to Publish 23 | * Create and push a branch with your new features. 24 | * When ready to publish a new production version, create a Pull Request from _feature branch_ to `master`. 25 | * The title of the pull request must contain a special semver tag: `[semver:]` where `` is replaced by one of the following values. 26 | 27 | | Increment | Description| 28 | | ----------| -----------| 29 | | major | Issue a 1.0.0 incremented release| 30 | | minor | Issue a x.1.0 incremented release| 31 | | patch | Issue a x.x.1 incremented release| 32 | | skip | Do not issue a release| 33 | 34 | Example: `[semver:major]` 35 | 36 | * Squash and merge. Ensure the semver tag is preserved and entered as a part of the commit message. 37 | * On merge, after manual approval, the orb will automatically be published to the Orb Registry. 38 | 39 | 40 | For further questions/comments about this or other orbs, visit the Orb Category of [CircleCI Discuss](https://discuss.circleci.com/c/orbs). 41 | 42 | -------------------------------------------------------------------------------- /src/tests/README.md: -------------------------------------------------------------------------------- 1 | # tests/ 2 | 3 | This is where your testing scripts for whichever language is embeded in your orb live, which can be executed locally and within a CircleCI pipeline prior to publishing. 4 | 5 | # Testing Orbs 6 | 7 | This orb is built using the `circleci orb pack` command, which allows the _command_ logic to be separated out into separate _shell script_ `.sh` files. Because the logic now sits in a known and executable language, it is possible to perform true unit testing using existing frameworks such a [BATS-Core](https://github.com/bats-core/bats-core#installing-bats-from-source). 8 | 9 | ## **Example _command.yml_** 10 | 11 | ```yaml 12 | 13 | description: A sample command 14 | 15 | parameters: 16 | source: 17 | description: "source path parameter example" 18 | type: string 19 | default: src 20 | 21 | steps: 22 | - run: 23 | name: "Ensure destination path" 24 | environment: 25 | ORB_SOURCE_PATH: <> 26 | command: <> 27 | ``` 28 | 29 | ## **Example _command.sh_** 30 | 31 | ```bash 32 | 33 | CreatePackage() { 34 | cd "$ORB_SOURCE_PATH" && make 35 | # Build some application at the source location 36 | # In this example, let's assume given some 37 | # sample application and known inputs, 38 | # we expect a certain logfile would be generated. 39 | } 40 | 41 | # Will not run if sourced from another script. 42 | # This is done so this script may be tested. 43 | if [[ "$_" == "$0" ]]; then 44 | CreatePackage 45 | fi 46 | 47 | ``` 48 | 49 | We want our script to execute when running in our CI environment or locally, but we don't want to execute our script if we are testing it. In the case of testing, we only want to source the functions within our script,t his allows us to mock inputs and test individual functions. 50 | 51 | **A POSIX Compliant Source Checking Method:** 52 | 53 | ```shell 54 | # Will not run if sourced for bats. 55 | # View src/tests for more information. 56 | TEST_ENV="bats-core" 57 | if [ "${0#*$TEST_ENV}" == "$0" ]; then 58 | RUN CODE 59 | fi 60 | ``` 61 | 62 | **Example _command_tests.bats_** 63 | 64 | BATS-Core is a useful testing framework for shell scripts. Using the "source checking" methods above, we can source our shell scripts from within our BATS tests without executing any code. This allows us to call specific functions and test their output. 65 | 66 | ```bash 67 | # Runs prior to every test. 68 | setup() { 69 | # Load functions from our script file. 70 | # Ensure the script will not execute as 71 | # shown in the above script example. 72 | source ./src/scripts/command.sh 73 | } 74 | 75 | @test '1: Test Build Results' { 76 | # Mock environment variables or functions by exporting them (after the script has been sourced) 77 | export ORB_SOURCE_PATH="src/my-sample-app" 78 | CreatePackage 79 | # test the results 80 | grep -e 'RESULT="success"' log.txt 81 | } 82 | 83 | ``` 84 | 85 | Tests can contain any valid shell code. Any error codes returned during a test will result in a test failure. 86 | 87 | In this example, we grep the contents of `log.txt.` which should contain a `success` result if the `CreatePackage` function we had loaded executed successfully. 88 | 89 | ## See: 90 | - [BATS Orb](https://circleci.com/orbs/registry/orb/circleci/bats) 91 | - [Orb Testing CircleCI Docs](https://circleci.com/docs/2.0/testing-orbs) 92 | - [BATS-Core GitHub](https://github.com/bats-core/bats-core) 93 | -------------------------------------------------------------------------------- /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2.1 2 | 3 | orbs: 4 | # Replace this with your own! 5 | : /@<> 6 | orb-tools: circleci/orb-tools@10.0 7 | bats: circleci/bats@1.0 8 | shellcheck: circleci/shellcheck@2.0 9 | 10 | # Pipeline Parameters 11 | ## These parameters are used internally by orb-tools. Skip to the Jobs section. 12 | parameters: 13 | run-integration-tests: 14 | description: An internal flag to prevent integration test from running before a development version has been created. 15 | type: boolean 16 | default: false 17 | dev-orb-version: 18 | description: > 19 | The development version of the orb to test. 20 | This value is automatically adjusted by the "trigger-integration-tests-workflow" job to correspond with the specific version created by the commit and should not be edited. 21 | A "dev:alpha" version must exist for the initial pipeline run. 22 | type: string 23 | default: "dev:alpha" 24 | 25 | jobs: 26 | # Define one or more jobs which will utilize your orb's commands and parameters to validate your changes. 27 | integration-test-1: 28 | docker: 29 | - image: cimg/base:stable 30 | steps: 31 | - checkout 32 | # "greet" is a sample command packaged with this orb config. 33 | # This sample integration test will run as long as the greet command exists. Once you remove the greet command you should remove this line. 34 | # Push new changes first, before adding new tests to your config. 35 | - /greet 36 | 37 | workflows: 38 | # Prior to producing a development orb (which requires credentials) basic validation, linting, and even unit testing can be performed. 39 | # This workflow will run on every commit 40 | test-pack: 41 | unless: << pipeline.parameters.run-integration-tests >> 42 | jobs: 43 | - orb-tools/lint # Lint Yaml files 44 | - orb-tools/pack # Pack orb source 45 | - shellcheck/check: 46 | dir: ./src/scripts 47 | exclude: SC2148 48 | # optional: Run BATS tests against your scripts 49 | - bats/run: 50 | path: ./src/tests 51 | # Publish development version(s) of the orb. 52 | - orb-tools/publish-dev: 53 | orb-name: / 54 | context: # A restricted context containing your private publishing credentials. Will only execute if approved by an authorized user. 55 | requires: 56 | - orb-tools/lint 57 | - orb-tools/pack 58 | - bats/run 59 | - shellcheck/check 60 | # Trigger an integration workflow to test the 61 | # dev:${CIRCLE_SHA1:0:7} version of your orb 62 | - orb-tools/trigger-integration-tests-workflow: 63 | name: trigger-integration-dev 64 | context: 65 | requires: 66 | - orb-tools/publish-dev 67 | 68 | # This `integration-test_deploy` workflow will only run 69 | # when the run-integration-tests pipeline parameter is set to true. 70 | # It is meant to be triggered by the "trigger-integration-tests-workflow" 71 | # job, and run tests on @dev:${CIRCLE_SHA1:0:7}. 72 | integration-test_deploy: 73 | when: << pipeline.parameters.run-integration-tests >> 74 | jobs: 75 | # Run any integration tests defined within the `jobs` key. 76 | - integration-test-1 77 | # Publish a semver version of the orb. relies on 78 | # the commit subject containing the text "[semver:patch|minor|major|skip]" 79 | # as that will determine whether a patch, minor or major 80 | # version will be published or if publishing should 81 | # be skipped. 82 | # e.g. [semver:patch] will cause a patch version to be published. 83 | - orb-tools/dev-promote-prod-from-commit-subject: 84 | orb-name: / 85 | context: 86 | add-pr-comment: false 87 | fail-if-semver-not-indicated: true 88 | publish-version-tag: false 89 | requires: 90 | - integration-test-1 91 | filters: 92 | branches: 93 | only: 94 | - master 95 | - main 96 | --------------------------------------------------------------------------------