Jira Integration - "Releases"
Please rename the heading "Releases" to "Deployments" within Jira. We are trying the CircleCI JIRA integration. It is showing CircleCI Deployment data within an individual JIRA ticket, on the right hand side of the JIRA Ticket. This information is shown under the title "Releases", but I think it should be "Deployments", as per DevOps convention. These may be Deployments to non-production environments, and doesn't account for when we use Feature Flag tools to Release software. Also, when you actually click on the Releases info, it brings you to a menu titled "Deployments"!
Allow list-type parameters in Orbs
It'd be useful to allow handling lists of values for a parameter, without having to resort to workarounds like parsing comma-separated lists in string types. I think it would be useful to be able to specify something like: steps: - myorb/foo: bar: - baz - qux And have the myorb/foo command called with a bar parameter equal to [ "baz", "qux" ] . CCI-I-701
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" CCI-I-606
Mark skipped job with gray icon
I have a few workflows where we evaluate a branch for changed paths and do a circleci step halt if there are no hits. This works well enough, but the issue is that in the UI the job containing step is still marked in green (as is the skipped job). Ideally we would have a halt syntax that allowed recording a success, failure, or new (as far as I can tell) "skipped" state for the jobs that didn't run for a particular invocation (e.g. a PR changeset). CCI-I-1496
Workflows in orbs
I want to be able to define an entire workflow in an orb, using the jobs of my orb and allowing parameters to conditionally choose which jobs to run and allow parameterization of branch and tag filters as well. CCI-I-615
Private Orb Registry
As a company we often have parts of our build process that must remain private. It would be nice to be able to share configuration through orbs versus copying and pasting YAML from project to project however, we would not want this in the public registry. Is there or can their be support for hosting a private orb registry. If that is not available, offer private namespaces in the current registry? CCI-I-819
Allow uncertified orbs per project
Currently we can only "Allow Uncertified Orbs" globally for the whole organisation. It would be useful if we could do it on per-project basis. CCI-I-780
Allow deprecation of old orbs
Allow authors/publishers of orbs to manage deprecation of their orbs, giving them the ability to more adequately manage the orb's support lifecycle. Authors/publishers of orbs are potentially expected to support all published versions of an orb. Allowing publishers to deprecate and/or remove older versions of an orb would prevent authors/publishers from having to support older versions of an orb which may contain issues fixed in later versions.
Allow to use third-party orbs by white list
Currently "Allow Uncertified Orbs" of "Orb Security Settings" have binary option to allow to use third-party orbs or not.We wish to use WHITE LIST orb provider. CCI-I-687
Fetch Orb Versions via API
I would like an API endpoint to fetch all, or a subset of, semantic versions available for a given Orb. My goal is for dependency update tools, such as Renovate, Dependabot, Greenkeeper, etc., to use that API endpoint to fetch a list of available versions for a given Orb so that the tool can update the Orb where it's referenced in Circle CI configuration files. CCI-I-719