Orbs FAQ

22 days ago

Cloud Server v4+

This document describes various questions and technical issues that you may find helpful when working with orbs.

FAQs

What types of orbs are available?

CircleCI supports three types of orbs:

Registry orbs: Registry orbs can be developed using the orb dev kit (there is also a manual process) and published for use by anyone (public) or within your organization (private). Registry orbs follow strict semantic versioning. Public registry orbs are available from the Orbs Registry.

Registry orbs are available for many languages, platforms, services, and tools. Visit the Orbs Registry to search for orbs to help simplify your configuration.

If you would like to author your own registry orb, read more on the Create a Registry Orb page.
URL orbs: URL orbs are stored in a publicly accessible location (for example, a git repository or a public S3 object) and are not published to the orbs registry.

URL orbs do not follow semantic versioning, and can be accessed directly using an https URL. An org-level allow list is used to manage the addresses of URL orbs that can be used in a project in that organization. Organization admins can manage the allow list at Organization Settings Orbs.

See the Managing URL Orb Allow Lists guide for more information on scoping allowed URL orbs for your organization.

If you would like to author your own URL orb, see the Create, Test, and Use URL Orbs guide.
Inline orbs: Inline orbs are defined directly within your project’s configuration file. They are project-specific and not published or shared externally. Inline orbs are ideal for reusable configuration within a single project, and are also useful for learning orb concepts and testing configurations prior to extracting to a URL or registry orb.

Inline orbs do not require publishing, versioning, or external hosting. They exist only within your .circleci/config.yml file.

See the Create an Inline Orb guide for more information on creating inline orbs.

For a detailed comparison, see the Orb Types Comparison section.

Which orb type should I use?

Choose registry orbs when:

You want to share with the community.
You need semantic versioning.
You want discoverability in the Orb Registry.

Choose URL orbs when:

You need to share configuration across your organization.
You need direct control over updates.
Configuration contains proprietary logic.

Choose inline orbs when:

Configuration is specific to one project.
You want zero publishing overhead.
You are learning about orbs and want to experiment.
You want to test out packaging some configuration before extracting it to a URL or registry orb.

See the Choosing an Orb Type section for more guidance.

Can registry orbs be made private?

Private Registry Orbs are available on any of our Current Plans. Inline orbs are inherently private to the project. URL orbs are controlled by your organization’s allow-list and hosting access.

What is the difference between commands and jobs?

Both Commands and Jobs are elements that can be used within orbs.

Commands contain one or many Steps, which contain the logic of the orb. Commands generally execute some shell code (Bash).

Jobs are a definition of what steps/commands to run and the Executor to run them in. Jobs invoke commands, and are orchestrated using Workflows.

Can orbs be used on a private installation of CircleCI Server?

Orbs can be used with installations of CircleCI Server. For information on importing and using orbs for server, see the CircleCI Server Managing Orbs page.

How can I report a bug or issue with a public orb?

All public orbs are open source projects. Issues, bug reports, or even pull requests can be made against the orb’s git repository. Public orb authors may opt to include a link to the git repo on the orb registry. If the git repo link is unavailable, contact support and we will attempt to contact the author. Alternatively, consider forking the orb and publishing your own version.

How do I use the latest version of a registry orb?

Registry orbs use semantic versioning. If you set the major version (example: 3), you will receive all minor and patch updates. If you statically set the version (example: 3.0.0), no updates will apply. Using a static version is the most deterministic and recommended method.

Inline orbs do not have versions (updated by editing the config file), and URL orbs use Git-based versioning (branches, tags, or commits) rather than semantic versioning.

NOT RECOMMENDED - It is possible to use @volatile to receive the last published version of an orb. This is not recommended as breaking changes are expected.

[path]

[title]