Orbs documentation is unclear
matfax opened this issue · 4 comments
I couldn't figure out how to migrate an inline orb to a proprietary one. Is there a documentation for that?
Also, I'm not sure if orbs can be published globally via a git repository or if they are always delimited to your current repository's build.
Meanwhile, I tried the new CLI and reread the documentation. Now, I understand that, unlike Docker, you do not intend to create an open repository, but only one for trusted partners? Anything I try with the CLI results in an Error: AUTHORIZATION_FAILURE.
Hey @matfax, we're currently working on building an public registry for orbs--one where you can publish and use orbs that you or others have created. The slow part right now is that this will require a new TOS, since we'll be publishing the source of orbs you send us, and potentially running third-party "code" during your CircelCI builds (if you use third-party orbs). Accepting this TOS and signing up to publish or use "uncertified" orbs is likely to be a project or org setting, after which you'll be able to publish and use your own (or someone else's) orbs just by referring to them in config.
In the meantime, our current thinking is that we can write our own vetted "certified" orbs and let anyone use them while we hammer down the legal stuff required for a truly public orb registry.
Sorry, I realize this is all totally unclear from our docs and error messages--this is definitely something we're aiming to improve!
Thank you for clarifying, @johnswanson. Is there maybe some other alternative to reuse orbs among projects soon? I'm also thinking of the scenario of private git repositories. In 2.1, will the requirement remain that there is only one file named config.yml? There has already been a request for multiple configs under Idea CCI-I-246. That way, you could define inline orbs per file and make reuse easier. Another way, I could imagine, is the integration of git submodules, where the submodules contain a separate reusable space (e.g., subfolder name, or yaml context) so that existing submodules are not affected.
@matfax The current plan is that the core platform does require you to have a single file for config, however we are looking at a couple ways to help people break up their large configs. Within config the 2.1 features should help to reduce, sometimes dramatically, the size of configuration files. Reusable commands, parameterized jobs, and reusable executors should help make configuration much more DRY. In addition, we are working on formalizing the functionality in the new CLI command circleci config pack, which can take a set of folders and files containing decomposed YAML and pull it all into one. We don't yet have a way to do that at build-time, but you can manage your config locally and regenerate it -- this isn't ideal, but it's the seed of formalizing a way to collapse config from several files in the future. This issue has become about a couple different things, and we are capturing the work elsewhere to clarify orb publishing shortly, so I'm going to go ahead and close this.