allow private namespaces for orbs w/ CircleCI

Many organizations using orbs would most likely want to publish their orbs privately.

I assume orbs will be scoped to your GitHub org as namespace?

So it would be great if we can publish orbs to foobar/wizzle (assuming GH org foobar), and to have those be only visible to users / jobs within org "foobar"

  • Guest
  • Sep 17 2018
  • Candidate
  • Attach files
  • Luke Thompson commented
    07 Aug 01:32

    +1 from us too. It would be really useful for us. Particularly if the Orbs could be really simple to publish / not require publishing just drawn from a repository.

  • Cory Dorning commented
    21 Jul 13:19

    Is this on the CircleCI roadmap or planned for a future release?

  • Sven Ulrich commented
    26 Jun 08:32

    I also couldnt make the workaround work. Is there an example around?

  • Daniel Demmel commented
    19 Jun 12:22

    I was a bit shocked to find out that this is not possible...

    Tried the workaround posted at 07 May 00:24 but it didn't work.

    A Git based solution as an alternative source would be most welcome!

  • Nick Chen commented
    17 Jun 19:43

    +1 since it's useful to have private orbs to not share details in the .yml file.

    When private orbs are allowed, I assume that https://circleci.com/orbs/registry/licensing would also no longer be applied to the orb listings? The reason being that no one else should be able to see the orbs and, thus, they are no longer open source.

    Having the MIT license applied to private orbs is a bit confusing when the orb is meant be closed source and not shared with anyone else.

  • Nayo Akinyele commented
    17 Jun 15:01

    +1

  • Michael Bailey commented
    07 May 00:24

    You should be able load an orb from any repo in the same org as the repo building built.

    Config would look like:

    orbs:
    my-orb:
    repo: my-private-orbs
    version: v1.2.3
    path: my-orbs/orbs.yml

    Circle already has the auth setup for the linked Github org `my-linked-org` , so the above config would use that auth to load:

    https://raw.githubusercontent.com/my-linked-org/my-private-orbs/v1.2.3/my-orbs/orbs.yml

  • Kevin Morton commented
    04 May 22:10

    +1

  • Ned Lucks commented
    30 Apr 07:00

    +1 we could really use this with about 500 projects sharing the same private build steps.

  • Marc Destefanis commented
    16 Apr 14:00

    Any updates?

    I've seen that we can unlist orbs from the registry search results by using the CLI. But it's not enough as orbs are still world-readable and can therefore be used if referenced with a valid name.

    We would need private orbs on the organisation level.

  • Glenn Nagel commented
    08 Apr 14:09

    I'd love to see this ASAP, this is one of the features we get out of GCP that I would like to see here too.

  • A Al commented
    30 Mar 21:13

    Any updates Circle team?

  • Ilya Trushchenko commented
    20 Feb 18:55

     I can't believe it's still not implemented! 2 years!!!

  • ANDREW HILTON commented
    24 Jan 14:13

    +1

  • Joao Henrique Machado Silva commented
    19 Jan 22:24

    It's really a shame that this feature does not exists yet. It seems like a trivial thing to have in my opinion. And very important based on the amount of comments. 

  • Bryan Campbell commented
    December 19, 2019 20:06

    Today we opened 160 PRs to update our build configs from node 10 to node 12. Sure would be nice to be able to centralize our configuration into a private orb.

  • Aviad Shikloshi commented
    December 09, 2019 08:58

    +1

  • Timothy c commented
    December 03, 2019 16:22

    Hidden is enough for our usecase

  • Igor Belikov commented
    October 16, 2019 07:53

    Any progress on this? This is the most upvoted idea, having some kind of solution for this (and unlisting is not a real solution for a lot of us here) would be greatly appreciated.

    I had to create ~70 pull requests recently just because using orbs is a no go until there are private namespaces. If there's no real timeline on having them, I'd rather spend my time on migrating away from CircleCI at all.

  • Giuseppe Landolfi commented
    September 23, 2019 07:28

    +1 from here as well. We're migrating to CircleCI and this one is the single most important thing that we miss. We're duplicating A LOT of config across projects because having our build steps public is not an option.

  • Load older comments