This should now be fixed. Can you please try again?
Yes it works as expected now.
Thanks for the help.
I have the same job
name in two workflows, and CircleCI creates
name-2 during executing. This of course means that Github won’t recognize these builds to satisfy that branch check constraints. I’m running into this issue with macOS builds, but I haven’t checked Linux builds. An example of this failure is in https://github.com/mapbox/mapbox-gl-native/commit/9acd689f2601cbdf4b51e155211c0d15a5620695
Looks like it’s possible to use the
name: field when instantiating jobs in different workflows to assign an explicit name. It still fails on duplicate assigned names, but I assume that’s due to limitations in the 2.0 syntax that it is being processed into.
Another feature request I have is for the processing step to load orbs (and potentially commands/jobs) from the file system. I know that this is possible with
circleci config pack, but that still requires an extra step before every commit.
Is there no way to make entire jobs conditional within a workflow? Is that coming in version 2.1 of workflows?
Is the plan to keep conditional steps determined before execution forever?
We’re interested in making it easier to package orbs alongside your build, though it’s not clear of pulling them out of your repo is the best way to get that done. One issue is that it would increase the API traffic to GitHub (or other VCS) at the start of your build and make the config-processing step more complicated and slower. Assuming we could overcome that issue, curious know if you would want your “local” orbs to be broken out into files for use with
@brandonpage - would you envision some kind of top-level
when clause like conditional steps? What would you want to evaluate for deciding to run a job?
Can you provide your config that reproduces the “still fails on duplicate assigned names” problem you’re seeing?
@ndintenfass I envisioned a when at the same level as requires/context under a job in a workflow.
I work on an sdk that has a handful of distinct libraries in one mono-repo so it was very easy for me write a script to determine which libraries are changed by a pr. Currently I launch a job for each and halt the ones that aren’t affected by the pr. Would be much cleaner to only start jobs for the libraries that need to run.
Are you really going to keep the
<< variable >> syntax ?
- It conflicts with YAML anchors.
- It conflicts with bash (and other languages) syntax for Here documents.
That’s just making sure we’ll need to stack up escape sequences and make config files unreadable and hard to maintain.
It is actually worse than I thought:
echo <<EOF EOF
[...] # ('<<' must be escaped in v2.1+) false Exited with code 1
cat \<\<EOF EOF
cat: <<EOF: No such file or directory Exited with code 1
The right syntax is:
cat \<<EOF EOF
Really feels like a very poor choice in syntax.
I have started messing around with Orbs and am confused by how it is expected we keep track of the version number. In a JS project the version number would be written in the
package.json. I see in the circleci-orbs project there is a
orb-releases.yml, but I cannot find any documentation on that file. Any guidance from the team?
For those interested, I have written auto-published orbs for our org located here. CircleCI will automatically create, validate and publish any orbs located in the
Thank you! The fact that this is completely undocumented makes it even worse. At the very least please make this clear in the error message or documentation.
@aldesantis: this is a pre-release feature, so I’d expect some things to be undocumented.
Feedback/question: if I have a build that uses an orb with the version specified as
@volatile, is there any way to see the version that
@volatile resolved to for that build?
It would be helpful to know the version that
@volatile resolved to for the build so that I can explicitly pin to that if necessary. It would also help if it were possible to list all of the versions for a specific orb using the CLI.
When I view the build configuration for the job in the UI, it shows the fully rendered configuration so it’s always possible to copy-paste that to reproduce the build, but I think it would be extremely helpful if the UI also explicitly listed the versions that all of the
@volatile references in the build resolved to.
This is the scenario that made me want this:
- A new build of my project ran and failed because it referenced an orb using
@volatileand the orb was updated with a breaking change since the last build of my project
- I wanted to put off dealing with the underlying issue, so my desire was to just replace the
@volatilereference with the concrete version that was used by the last successful build
- I was unable to find version resolution information in the build UI and couldn’t list versions in the CLI and ultimately had to find the source repo for the orb and determine the version manually
We’re in a similar boat: we’d like to use orbs privately within our repos, but not publish to the main registry:
- It’s very easy to accidentally reference private data (secrets, package names, containers, etc)—and extremely hard to validate it.
- Contexts cover most of the secrets hiding, but are cumbersome in this …context:
- Naming vars used in orbs by convention in a way that encourages reuse is hard (for example, some of our workflows may juggle multiple AWS creds, a commit identity, etc)
- Contexts can’t be composed; which is going to imply that we’ll probably have a kitchen sink context with all the things—or a myriad of contexts tailored per orb, with a lot of duplicated values
- We’d rather not build our orbs in a way that supports community use cases (aka not ready for the burden of OSS maintainership)