Don't run deploy workflow step for forked PR


#1

This was unexpected. A forked pull request that was submitted from a master branch instead of a feature branch.
https://circleci.com/gh/ppreeper/edmontongo.org/2

The deploy step is set up to only run on the master branch – my intent was only run deploys on my master branch when a pull request is merged (or for direct pushes to master, I suppose).

workflows:
  version: 2
  build:
    jobs:
      - build
      - deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - master

However, the deploy step still kicked in. It was a master branch after all.

I don’t see any filtering options related to the repository location – though there seem to be several requests on the forums for filtering based on pull requests or forked pull requests. https://circleci.com/docs/2.0/configuration-reference/#filters

Disabling “Build forked pull requests” in Advanced Settings isn’t quite what I want either. I still want build and test steps to run on pull requests, just not the deploy step. (Oddly, this option is currently disabled and I don’t remember disabling it, so I’m not sure if it has any impact on CircleCI 2.0 workflows anyway).

For now the deploy just fails due to missing credentials (good), but it would be nice if it didn’t run and CI passed. What to do?


#2

This is a great question.

Right now there is no way to filter based on if it is your master or some other branch named master. The simplest approach is to let the build fail. A more complex approach would be to add a check (in bash or something) to verify the origin of the branch and then return something like “Not deploying due to fork”.

Both of those approaches would still have the build run. If the desire is to skip the build completely, then this would be a new feature request. I think its a great idea, I would encourage you to open one up on our public ideas board: https://circleci.com/ideas/


#3

I don’t necessarily want to skip the whole build, just that step of the workflow. The same behaviour as if it was another branch.


#4

Sorry I overloaded the word “build” in that context. I mean the same thing that you did.

Thanks for adding the feature request!