cypress-io / circleci-orb

Install, cache and run Cypress.io tests on CircleCI with minimal configuration.
https://circleci.com/orbs/registry/orb/cypress-io/cypress
MIT License
160 stars 101 forks source link

cypress/run: working_directory not used when storing artifacts #278

Closed mkorpela closed 4 years ago

mkorpela commented 4 years ago

The orb does not work as expected

    cypress/run:
          command: yarn cypress run --env MODE=staging
          yarn: true
          working_directory: frontend
          store_artifacts: true
          cache-key: 'cache-{{ arch }}-{{ checksum "frontend/package.json" }}'
          requires:
            - deploy-staging
          filters:
            branches:
              ignore:
                - master
mkorpela commented 4 years ago

My command until someone fixes this: command: CYPRESS_videosFolder=../cypress/videos yarn cypress run --env MODE=staging

bahmutov commented 4 years ago

Can you show the resolved config for this job please?

https://github.com/cypress-io/circleci-orb#effective-config

There was a fix for store artifacts with custom working directory in https://github.com/cypress-io/circleci-orb/releases/tag/v1.19.2 and there is a test for this

mkorpela commented 4 years ago

It’s not a problem for me anymore thus I’m not going to invest more time on this. I’ve reported the problem on the level of detail I assume to be enough for reproducing the problem. Thus ”needs more info” seems like ignorance.

mkorpela commented 4 years ago

Ok blaah you win :(

  cypress/run:
    docker:
    - image: cypress/base:10
    parallelism: 1
    environment:
    - CYPRESS_CACHE_FOLDER: ~/.cache/Cypress
    steps:
    - run:
        command: echo "Assuming dependencies were installed using cypress/install job"
    - attach_workspace:
        at: ~/
    - checkout
    - restore_cache:
        keys:
        - cache-{{ arch }}-{{ checksum "frontend/package.json" }}
    - run:
        name: Install
        working_directory: frontend
        command: "if [[ ! -z \"\" ]]; then\n  echo \"Installing using custom command\"\n  echo \"\"\n  \nelif [ \"true\" = \"true\" ]; then\n  echo \"Installing using Yarn\"\n  yarn install --frozen-lockfile\nelif [ ! -e ./package-lock.json ]; then\n  echo \"The Cypress orb uses 'npm ci' to install 'node_modules', which requires a 'package-lock.json'.\"\n  echo \"A 'package-lock.json' file was not found. Please run 'npm install' in your project,\"\n  echo \"and commit 'package-lock.json' to your repo.\"\n  exit 1\nelse\n  echo \"Installing dependencies using NPM ci\"\n  npm ci\nfi\n"
    - run:
        name: Verify Cypress
        command: npx cypress verify
        working_directory: frontend
    - save_cache:
        key: cache-{{ arch }}-{{ checksum "frontend/package.json" }}
        paths:
        - ~/.cache
    - persist_to_workspace:
        root: ~/
        paths:
        - project
        - .cache/Cypress
    - run:
        name: Run Cypress tests using custom command
        command: yarn cypress run --env MODE=staging
        no_output_timeout: 10m
        working_directory: frontend
    - store_artifacts:
        path: cypress/videos
        working_directory: frontend
    - store_artifacts:
        path: cypress/screenshots
        working_directory: frontend
mkorpela commented 4 years ago

And

# Original config.yml file:
# version: 2.1
# orbs:
#   cypress: cypress-io/cypress@1.21.0

Ping @bahmutov

bahmutov commented 4 years ago

Hmm, looking at https://circleci.com/docs/2.0/artifacts/ and https://circleci.com/docs/2.0/configuration-reference/#store_artifacts I see that working_directory does not affect store_artifacts, not sure why I thought this is a parameter. A bug, let's try appending the working directory instead

mkorpela commented 4 years ago

Still I have to say that I think that you could have reproduced the problem with the original bug report. Ofcourse there was a level of disbelief as you had already “fixed” the problem. Might be a good idea to make it easier for you to try out real circleci configs to get fast validation. Also that would have prevented the problem that in 1.19.2 this was “fixed” - you would have noticed that this does not work.