If you expected a workflow to run, check your config contains a top-level key called 'workflows:'

I am seeing this error even though my .circleci/config.yml file has a top level workflows entry.

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:'

Failed build: https://circleci.com/gh/anishkny/greenkeeper-test-drive/2

Heres my config:

version: 2

      - image: circleci/node:8.5.0-browsers
      - image: circleci/mongo:3.4.9
      - checkout
      - restore_cache:
          key: node-modules-{{ checksum "yarn.lock" }}
      - restore_cache:
          key: sut-node-modules-{{ checksum "sut/yarn.lock" }}
      - run:
          name: Start app and test
          command: |
            yarn run start
            yarn run test
      - save_cache:
          key: node-modules-{{ checksum "yarn.lock" }}
            - ./node_modules
      - save_cache:
          key: sut-node-modules-{{ checksum "sut/yarn.lock" }}
            - ./sut/node_modules/
      - store_artifacts:
          path: ./.screenshots
          destination: screenshots

  version: 2
      - test

It seems to be fixed if I “touch” the config file in my repo (e.g. by making a whitespace only change).

Is it still fixed? I know this is apparently just a test but I wouldn’t name the workflow the same name as job. My initial thought is that that may have been the issue. At the very least, it’s confusing.

I had similar issue.
I also have job name test but my workflow is called test-and-deploy.
I committed circle .circleci/config.yml and setup project.
Workflow wasn’t detected properly at first build and it was expecting job name build like in @anishkny case.
Change in config file fixed it.

1 Like

Is it still fixed? I know this is apparently just a test but I wouldn’t name the workflow the same name as job. My initial thought is that that may have been the issue. At the very least, it’s confusing.

This will happen on the first build on every new repository. I have been migrating a large number of repositiories recently because I am dissecting this monorepo into individual repositories for each package (e.g. this and this).

Essentially, as soon as I enable CircleCI, and with .circleci/config.yml already present (they are very similar so I just copy them over prior to enabling the service), my first build will always fail with the above described error. A rebuild with the “rebuild” button will fail again. But as soon as I push a change to the repo, no matter how trivial, it starts working.

same problem here

fixed by touching the config file as described by the OP

is it a known issue for CircleCI?

my workflows do not have the same name as the jobs, I copied the example config from here:

and adapted to Python… so I have jobs named “python-2.7” and “python-3.6” and a single workflow named “build”

the config works fine, but not when you initially connect the Github project

I just verified that this bug also happens when someone forks a repository and sets up the project to build. Making any update to the config.yaml file (i.e. add a #) fixes the problem.

I observed the same problem at:

I’m loving the workflows working as expected on the master branch,
I saw some threads reporting problems just one month ago.
Thanks CircleCI!

As a note, this is still a problem.
(A co-worker of mine just hit this, and thought his YAML file was invalid.)

Same problem here. This is not a great first user experience…


Same problem here.
Made several changes to the config file, but nothing seems to circumvent the issue. Really weird.

I ran into this while renaming repositories. It’s a terrible user experience, and, frankly, surprised a company like CrcleCI (which thrives because it’s a better experience than Travis) would allow it.

I’m shocked that there’s been no progress on this. I just ran into this, stumbled over this while googling, and I’m in disbelief. This was a horrible “lets try workflows!” experience.


Ahem! Several times I have intervened on this board to ask people to remember their manners, and I hope I can be permitted to do the same again here. In a variety of fora, I try to encourage (potential) customers not to dismiss people’s hard work in terms that may be seen as undiplomatic at best, or even aggressive. This is partly because it is good to treat fellow humans with maximum respect, but it is also the observation that if people perceive your remarks as rude, you may be less likely to obtain the change you are seeking.

More thoughts on this theme are here and here. I am, incidentally, merely a satisfied user on the free tier. CircleCI might not be perfect, but I think it is pretty darn good.

(cc several earlier prior commenters on the thread, probably :blush:)

1 Like

I am not impressed with CircleCI 2.0. I wished we just used Jenkins. I’m shocked … and I’s in disbelief how horrible my experience is. I have created fastlane that run everything perfectly on my local environment but have to move bunch of stuff to CircleCI as it times out on things as cocoapods. The worst is that everything I moved to CircleCI I can’t test locally as the circleci doesn’t support running jobs nor workflow. I am finally move my stuff to another repo so I don’t need to generate notification for the entire team but wow, it doesn’t work - the same config.yml I have working on other repo doesn’t work!!! Even after I tried the hack of updating something. Very disappointed - this is not our full time job to maintain the iOS builds and I just wanted something to work. By the way, we are paid customer and not using CircleCI for free.

1 Like

I doubt you’ll get a response to that @meiyuss, and I am not sure it merits one. If you can set out a specific problem you’re having, on a separate thread, with a view to solving it with a positive frame of mind, then perhaps you’ll get some ideas on how to tackle it.

Also, CI is hard, whoever your provider is. I don’t know what your experience level is, nor do I wish to offend you, but using hosted platforms does not make everything suitable for beginners. It took me an hour or two to debug a MariaDB/PHP problem for someone here the other day, since there were several inter-related issues. Nearly everyone who sets up a non-trivial CI system will encounter the same.

Dear halfer,

CI is hard and we expect some basic debugging or verification tool so we don’t need to upload any little changes to the server and wait for a long time to it to fail or return false failure. For example, this problem reported is a false failure. For example Jenkins I can totally test my solutions locally before push to a server. That is what I asked - a way to test locally and fit it myself quickly without spending time to explain my little problem and uploading my code and configuration each time. Also some problems I searched just closed without fixing. I just want a easy way to test my stuff and I don’t think that is too much for any paid customer to ask.


Well, maybe. Bear in mind that I am just a satisfied free tier user, so I have no sway here, but my response to your post is that you’re here to rant and not to get your problems solved. I don’t mean that as an insult - I mean to try to show you that it serves no productive purpose, and that a negative attitude will actively dog your experience of the platform henceforth, unless you make an effort to change direction.

This will be my last reply.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.