Fabric Support?

envars
python
circle.yml

#1

According to the docs, there is first class support for Fabric on machines running Python.

Does anyone know if something has recently changed in Circle’s support of this? I ran a deploy with no changes to my circle.yml file and got fab command not found errors.

Here’s my circle.yml file:

machine:
  node:
    version: 0.12.9
  python:
    version: 2.7.3

test:
  override:
    - ./node_modules/ember-cli/bin/ember test:
        pwd:
          ./overhaul

dependencies:
  pre:
    # these are the lines I had to add in order for the build to complete
    - export ac_cv_func_malloc_0_nonnull=yes
    - pip install fabric PyCrypto
    # end added lines
    - npm set progress=false
    - npm install -g bower
  override:
    - pip install --upgrade pip
    - pip install -r requirements.txt
    - npm i:
        pwd:
          ./overhaul
    - bower i:
        pwd:
          ./overhaul
  cache_directories:
    - overhaul/node_modules
    - overhaul/bower_components

deployment:
  prod:
    branch: prod
    commands:
      - ./node_modules/ember-cli/bin/ember deploy production --verbose --activate:
          environment:
            AWS_ACCESS_KEY_ID: $DEPLOY_AWS_ACCESS_KEY_ID
            AWS_SECRET_ACCESS_KEY: $DEPLOY_AWS_SECRET_ACCESS_KEY
            AWS_BUCKET: $PROD_AWS_BUCKET
            AWS_REGION: $PROD_AWS_REGION
            SSH_TUNNEL_USERNAME: $DEPLOY_SSH_TUNNEL_USERNAME
            SSH_TUNNEL_HOST: $DEPLOY_SSH_TUNNEL_HOST
            SSH_TUNNEL_DESTINATION_HOST: $PROD_REDIS_HOST
            SSH_TUNNEL_DESTINATION_PORT: $PROD_REDIS_PORT
            FINGERPRINT_PREPEND_URL: $PROD_FINGERPRINT_PREPEND_URL
          pwd:
            ./overhaul
      - fab prod m:"$CIRCLE_COMPARE_URL" r:$CIRCLE_SHA1 deploy --gateway $DEPLOY_SSH_TUNNEL_USERNAME@$DEPLOY_SSH_TUNNEL_HOST

#2

Hi,

I’m getting the same error when deploying, bash: line 1: fab: command not found. My circle.yml file looks like this:

machine:
    python:
        version: 3.5.1

test:
    override:
        - py.test tests/

deployment:
    production:
        branch: master
        commands:
            - fab -H <our_dev_server> -f scripts/deploy.py -u ubuntu deploy

Any clues? Thanks a lot!


#3

Are you using our Ubuntu 14.04 container or the older 12.04 container?

When I tried this with our 14.04 container I got

(venv-system) ubuntu@box61:~$ which fab
(venv-system) ubuntu@box61:~$ fab
The program 'fab' is currently not installed. You can install it by typing:
sudo apt-get install fabric

which seems to be an error, I’m going to go ask and file a ticket to fix this


#4

Yeah so I just ended up installing fab manually in my circle file, which is unreal for something that claims first-class support for a dep.

dependencies:
  override:
    - pip install fabric

#5

We do a lot of automatic changes and installs based on what our inference engine reports the project requires, it could be that your project has items that fooled the engine into thinking it was not a Python project.

Even with that, yes, we should have caught this sooner. I’m going to be filing an internal bug to ensure fabric is added and tests are in place to confirm.

thanks


#6

Thanks for the response. I had a feeling it was based on inferences. Would it make sense to allow users to be explicit about build environment requirements? For instance I am dealing with a monolith codebase that has Node, Ruby, and Python deps in a single repo (don’t get me started).

So my dependencies section now looks like:

dependencies:
  override:
    - sudo apt-get update && sudo apt-get install ruby-sass
    - gem update --system
    - gem install compass --no-ri --no-rdoc
    - npm set progress=false
    - npm install -g bower --registry=https://npm.wnyc.net
    - npm i --registry=https://npm.wnyc.net:
        pwd:
          ./overhaul
    - bower i:
        pwd:
          ./overhaul
    - pip install pyaml fabric
  cache_directories:
    - overhaul/node_modules
    - overhaul/bower_components

#7

We have quite a few large build infra related items that I think will be very exciting once they leave the current stealth/internal testing.

We have a lot of customers who have hybrid projects like yours and they at the top of our thoughts for these changes.


#8