Possible spurious YAML validation failure reports in the UI

I recently came across something that (a) might have been a UI bug, and (b) may now be fixed. I tried to look at the affected builds just now, and cannot see any remaining evidence of it.

I think the problem is that while the YAML parser copes with references, the CircleCI config validation does/did not. Strangely, it seemed to report a YAML problem (something about missing required keys like “jobs”, IIRC - maybe the same as this?) but only if the build failed legitimately for some other reason. In other words, this report would be suppressed if the build succeeded (thereby proving the YAML was fine after all).

My YAML is here, lightly edited for security:

# Some useful repeated stanzas

docker-sign-in: &docker-sign-in
  name: Sign into Docker registry
  command: |
    docker login -u username -p ${GITLAB_CDDEMO_REGISTRY_TOKEN} registry.gitlab.com

only-deploy-tags: &only-deploy-tags
  filters:
    tags:
      only: /^deploy-.*/
    branches:
      ignore: /.*/

# Here are the jobs

version: 2
jobs:
  build:
    working_directory: /app
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - run:
          name: Start the Docker service
          command: service docker start
      - run: *docker-sign-in
      - run:
          name: Build application Docker image
          command: |
            docker build \
                --tag registry.gitlab.com/username/${CIRCLE_PROJECT_REPONAME} \
                .
      - run:
          name: Install test software
          command: |
            apk update
            apk --update add php7 openssl
            # Composer requirements
            apk --update add php7-openssl php7-json php7-mbstring php7-zlib php7-phar
            # PHPUnit requirements
            apk --update add php7-dom php7-mbstring
            # Give the PHP binary a nice name
            ln -s /usr/bin/php7 /usr/bin/php
            cd /app && sh /app/install/composer.sh
            php /app/composer.phar install
      - run:
          name: Start Docker container
          command: |
            docker run \
                --publish 8080:80 \
                --detach \
                --name ${CIRCLE_PROJECT_REPONAME} \
                registry.gitlab.com/username/${CIRCLE_PROJECT_REPONAME}
            docker ps
      - run:
          # Thanks to https://unix.stackexchange.com/a/5279
          name: Wait for container to be ready
          command: |
            timeout -t 5 sh -c 'while ! echo exit | nc localhost 8080; do sleep 0.5; done'
      - run:
          name: Run tests
          command: |
            /app/vendor/bin/phpunit
      - run:
          name: Stop Docker container
          command: |
            docker stop ${CIRCLE_PROJECT_REPONAME}
      - run:
          name: Push Docker image
          command: |
            docker push registry.gitlab.com/username/${CIRCLE_PROJECT_REPONAME}

  # @todo This doesn't do any deploying yet, process needs designing and finishing
  # See the technique here: https://dzone.com/articles/deploying-from-circleci-to-linode-and-other-vps-pr
  deploy:
    working_directory: /app
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - add_ssh_keys

workflows:
  version: 2
  # This runs on non-tag pushes
  untagged-build:
    jobs:
      - build
  # This only runs on deploy tags and not branches
  tagged-build:
    jobs:
      - build: *only-deploy-tags
      - deploy:
          <<: *only-deploy-tags
          requires:
            - build

I saw this either Wednesday or yesterday (Thursday). If a CircleCI developer has worked on the frontend recently, especially with logic relating to showing errors, this can probably be disregarded. I will ping the thread if it comes up again!

(Incidentally this config is an old version I dug out of the UI, and in fact this will not build, for a variety of reasons - I provide this one because it corresponds to an actual historical failure.)

We did fix a bug that may have been related – are you still seeing the problems?

Hi @ndintenfass, no - I could not replicate it by going into the UI when I posted this. I will keep my eye out for when I next get a build failure, but I wonder if it also needs references to be present in the YAML in order to trigger.

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