This should now be fixed. Can you please try again?
Yes it works as expected now.
Thanks for the help.
@ndintenfass, I’m running into an issue very similar (if not identical) to @gregorath
I have the same job name in two workflows, and CircleCI creates name-1 and 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
1 Like
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 config pack?
@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.
EDIT:
It is actually worse than I thought:
echo <<EOF
EOF
fails with:
[...]
# ('<<' must be escaped in v2.1+)
false
Exited with code 1
Trying:
cat \<\<EOF
EOF
fails with:
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.
6 Likes
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 src directory.
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)
1 Like
I can’t seem to get jobs triggered via the API to work when my config uses version 2.1. It works with 2.0, but not 2.1, even if I don’t use any 2.1-specific features. The job is triggered okay, but it fails immediately with the following error:
Build-agent version 0.1.799-f865b43f (2018-10-11T12:48:06+0000) Configuration errors: 2 errors occurred: * Configuration version 2.1 requires the “Enable Build Processing” project setting. Enable Build Processing under Project Settings -> Advanced Settings. * Cannot find a job named build to run in the jobs: section of your configuration file. If you expected a workflow to run, check your config contains a top-level key called ‘workflows:’
I get the same error regardless of whether there actually IS a job named “build”.
And yes, I have enabled build processing in the project.
My config is currently such that if I set the version to 2.1, it fails, but if I set it to 2.0, it works. This only affects jobs triggered via the api. not via webhook updates from github.
Is this a known problem?
1 Like
Yes, unfortunately the way the job triggering API works we cannot use it with Build Processing. The alternative is to use the newer endpoint for triggering a build: https://circleci.com/docs/api/v1-reference/#new-project-build (there are some caveats in the docs about the new endpoint relative to the older one).
Ah. Thanks for the response. The new endpoint is a help, but I was hoping to be able to pass parameters into the job.