This is a general thread for feedback on the new 2.1 features of config and the new build processing system. If you don’t yet have the build processing setting on your projects (under Advanced on the project’s Settings page) you will soon as we roll it out to more and more organizations.
3 Likes
Will this support approval of holds via API?
1 Like
We intend to support that in the future, but that is not part of this batch of features.
Pity, that’d be awesome. I’d see it making approval straight from let’s say a slack channel with a bot relatively straight forward. Hope it’s not too far away.
I took a closer look at what’s come. I can see a few places where I can use this. Oh, and I wanted to point out, conditional steps, YES!!!
Attempting to use the new ORB feature.
I’ve written a couple orb.yml files
circleci orb validate verify’s them
Next steps appear to be creating a namespace and then building an orb
I’m trying to run: circleci namespace create NS-NAME github ORG-NAME
This always fails with an auth failure, but no other information
Using cli v0.1.1130
Is the register open for use? Is there something else that needs to be setup?
I’ve had a chance to read through the documentation and play around with writing some inline orbs and things look good so far – I think the concepts here are very promising in helping us to vastly simplify the way we currently deal with parameterizing CircleCI build configuration across projects.
Question: is there currently any way to build/publish orbs? I’d like to test out composing orbs (writing orbs that import other orbs), but it doesn’t look like that’s possible with inline orbs, and I can’t figure out how to build/publish orbs so that I can reference them statically based on namespace and version. I’ve tried using the orb create and orb publish CLI actions, but can’t figure out how to make them work, and not sure if there’s a mechanism for building and referencing orbs locally.
I am trying the settings in docs but if I specify version: 2.1, it seems to be fail always.
It seems that query ValidateConfig returns below result.
version: 2
jobs:
config_processing_exception:
steps:
- run:
name: Unexpected exception processing config
command: |
echo Unexpected exception processing config
echo Please contact support
false
docker: [image: 'debian:stretch']
workflows:
version: 2
config_processing_exception: {jobs: [config_processing_exception]}
I want to test the parameters feature,
After update circleci cli ver 0.1.1160, the error seems to be fixed.
@ndintenfass What’s the support status level on these 2.1 config features, is it pre-beta/beta or other? This is the only place I’ve seen these features mentioned so far.
Thanks.
2.1 config is in preview, which means it’s still being tested. We have avoided “alpha” and “beta” because as a continuously deployed app they make less sense. We are actively taking any bug reports and feedback, though it’s not officially “launched” – the preview is intended for early adopters who want to try it out before we make it an official feature.
2 Likes
Awesome, that makes sense it being in preview, yep which I can see looking at the Advanced Settings. I’ll definitely be jumping on the bandwagon.
Nice. Think we’ll give this a try sooner rather than later.
Question: is there currently any way to build/publish orbs?
I’ll second this, I can’t see any way to publish the orbs documented (but I might have missed it).
I’ve just experimented with the new schema version and have a few things I’ve noticed:
- Currently jobs run under the 2.1 schema still show as “2.0” in the badges. It would be nice to be able to distinguish between them.
- I pushed a commit with a 2.1 schema to a project which didn’t have 2.1 enabled. I got a bunch of confusing schema errors. It would have been more useful to say “You tried to run this with a schema version of 2.1. This isn’t enabled for your project yet. To enable it, go here”
- Are orbs going to only be public? After reading the docs, the process of managing orbs seems a little bit opaque to me still.
Overall though I really like it, and I can see how it’s going to greatly reduce our config volume. Thanks!
1 Like
- I’ll look into getting a “2.1” notice on the UI.
- We are going to be fixing the issue of pushing 2.1 without build processing on - we’ll show better warnings soon
- For now all orbs will be “Open” (meaning anyone can run them). We will likely be adding a way to make private orbs, but we want to get the machinery working first and hear how people would want to restrict them before building in another security layer.
1 Like
So on our end, we’d love private orbs to lock down some of our docker image building and deploy parts of our CI/CD pipeline.
An example might be,
- A new project in our org
- We have set steps for building docker images and deploying that we would like to share between projects
- We would use contexts to inject the environment variables that we care about i.e. docker host, secret keys for our docker repos in AWS, etc… (to obfuscate them from employees pushing branches)
- We would use orbs to encapsulate the docker build and deploy jobs so that an employee could just add them to circle project and request someone with higher permissions add the right contexts to make them function.
For us in general, in order to use Circle for the entire CD pipeline we would like more options to lock down parts of that pipeline so that they are usable, but obfuscated.
1 Like
@jasonwc Understood – Assuming you’re using Contexts to lock down your secrets, curious to understand why the config in the orbs themselves would need to be private. Do they contain proprietary techniques? Or perhaps they expose endpoints or other network info that opens up surface area of attack? We’re looking into what models people need for protecting config and orbs and are researching what is acceptable to be Open vs. Closed. We have a working assumption with open orbs that people should avoid any secrets in config, so most cases of orbs themselves can be open. Assuming you could control orb publishing with in your org, would you be comfortable providing world-read access to the underlying orb and use fully locked-down environment variables for any thing secret? Or is the config itself sensitive?
Are there any plans to be able to display multiple projects together in the workflow UI?
A current use case for us developing for the Salesforce Platform, is that on our default branch, we have a workflow that (1)runs units tests, (2)uploads a new version to the package management system, (3)waits for that version to be installable, (4)then will install it. On the last job in the workflow(install) it will trigger our automated UI tests that are in another project.
Currently because there is no Workflow API we have to chain regular jobs together so we have zero visibility into the entire process. While we will add that visibility with the workflow api, I was wondering if we could get that UI to display a job from another project(in this case the automated tests)? This way you could view the workflow for the entire package instead of it being in another project.
Hello @ndintenfass,
the following code was working okay until a couple of days ago in version 2.1 but it is broken now.
workflows:
build1:
jobs:
- test:
filters:
branches:
ignore: master
- test2:
requires:
- test
build2:
jobs:
- test:
filters:
branches:
only: master
The error looks like:
We weren't able to start this workflow.
test2: requires job "test" but "test" is not part of this workflow.
The following jobs are unreachable: test2
Do you know if the breaking change is intentional?
Is there another way to achieve the same result in the new version?
---------added details
After running circleci process on the file I find out that the output contains two jobs, test-1 and test-2 while in version 2 there was only one job test.
So a solution for now seems to be like:
- test2:
requires:
- test-1
but it would be good to know if that is expected to work like this and if it is something that will stay like this.
1 Like