Feature: Full support for Private Orbs

[KyleTryon]

Problem:

There are a few considerations to take into account when publishing private orbs, which differ from the process to public orbs. I am creating this issue to track and discuss all private orb related issues with Orb-Tools so that we might find a common solution.

Issues:

• A #175 Describes an issue with the circleci orb validate command, which fails in private orbs.
• B #158 Review Check tests which are checking if the URLs in HomeURL and SourceURL are accessible, for private orbs, they may not be accessible.
• [ Collecting more data, have an issue with private orbs? Let us know here ]

Solution Discussion

1. Both of the issues above are resolved by adding appropriate parameters to the config.
   • To validate a private orb, your CIRCLECI_TOKEN must be present, which can be resolved by attaching your restricted publishing context to the pack job. Full comment
   • The Review Check tests RC006 and RC008 check for the validity of URLs supplied to the orb's display area. With a private orb, it is expected that the source_url tested by RC006 Full comment
     2. Could both issues be best resolved by improved error messaging?
     3. In the case of B, should test RC006 automatically assume the URL is unreachable for private orbs? This would require we inform the review step in some way that the orb is indeed private, possibly through a parameter.
        • It could be helpful to store as a project level environment variable, something such as isPrivate=true. However, if this is currently only helpful for the RC006 test, I think it may not be a worthy change yet.
        • It looks like form #142 there are at least a few users who are looking for this to be skipped "automatically".

[KyleTryon]

In response to Solutions, section 3.

should test RC006 automatically assume the URL is unreachable for private orbs?

As stated in this comment, we could specify an environment variable which specifies the orb is private. This environment variable could be automatically set with the orb init command in the CircleCI CLI as a part of the initialization process. The users could still manually resolve issues but we may be able to use the metadata to offer better error messaging or automated configuration.

[adamdmharvey]

Throwing a random idea out: What about elevating some metadata about the private nature of the orb into the @orb.yml? Obviously, at the moment that's assumed to be a standard set of orb metadata, and the only thing triggering an orb to be private is the commands I fire at the CLI to make it public or private or not.

Perhaps there needs to be an additional level of metadata, such that a key/value pair should be in the metadata that's checked against the permissioning. Say there was a value in the @orb.yml file, maybe visibility: private, and if the orb is being published a PUBLIC, there's a warning and a failure. (possibly one you could "accept" with a CLI flag?)

otherwise, it sort of feels like all of this "external" stuff i have to go to make it go private - i have to call the CLI differently when setting it up, (with the proposal outlined at top here) i have to add an environment variable to my build pipeline, etc. why add all these things if they could be part of the metadata and then automation could infer it?

[KyleTryon]

@adamdmharvey I somewhat agree. We actually wanted to do this back when we added the display key which includes your source url and home url, which didn't originally exist. I actually voted to call the key metadata. The issue is, orb config is CircleCI config, so anything that would become part of the orb source code, needs to be valid CircleCI config. That said, we could potentially strip that information out of the @orb.yml file when packing.

[KyleTryon]

Given the changes made recently, I think we can re-word this issue now to say that the only issue is that some tests, such as RC006 may not be expected to pass on a private orb. I will close this issue when #181 is merged, and open a new issue now expanding from this one.

[adamdmharvey]

Thanks for the work, Kyle & team !

[tdeekens]

@KyleTryon quick question. Orb-tools still seems to pull in 0.1.26094 through the Docker executor. If we bump that to 0.1.26343 passing org id and slug should work, right? Right now on it fails with orb-tools as the version of the CLI being pulled in doesn't support it yet.

[KyleTryon]

@tdeekens ahh good call thank you. I just saw it looks like the image was updated at least today: https://hub.docker.com/r/circleci/circleci-cli/tags

Let me know if it is still an issue.

I assume you were trying to take advantage of envsubst?

[tdeekens]

I assume you were trying to take advantage of envsubst?

No not really. Mainly given the default executor of the Orb pulling in 0.1.26094 here by default means by default orb-tools doesn't support private Orbs using private Orbs unless I am missing something.

[KyleTryon]

Ah no you are not wrong! Thank you @tdeekens. This is why we previously were not pinned to a tag, we'll need to issue a quick patch. Great call out thank you. Orb tools v12.0.1 incoming

[tdeekens]

Ah no you are not wrong! Thank you @tdeekens. This is why we previously were not pinned to a tag, we'll need to issue a quick patch. Great call out thank you. Orb tools v12.0.1 incoming

Thanks I was already wondering if I live twice as I was quite sure it was latest once 🐱 .

[tdeekens]

Thanks for the quick release. I am getting this error when publishing and I fail to trace it's origin. Can you help?

[KyleTryon]

Hey @tdeekens would you mind opening a new issue and sharing as much of your config as possible? Here it looks like no orb source file was passed to the publish command. We may need to see most or all of the config, it may help to write into the support team if there is any sensitive information.

Reference this template for using Orb Tools 12: https://github.com/CircleCI-Public/Orb-Template/tree/main/.circleci

[tdeekens]

Thanks. Maybe just an error then in adjusting the parameter names.