Builds are failing with django.db.utils.OperationalError: terminating connection due to administrator command

I have been running three successful builds with the same config file but now the builds are failing. Not sure why but the error returned is
django.db.utils.OperationalError: terminating connection due to administrator command

Here are my config defaults
defaults: &defaults
working_directory: ~/django-env
docker:
- image: circleci/python:3.6.4
environment:
PIPENV_VENV_IN_PROJECT: true
DATABASE_URL: postgres://postgres:postgres@localhost:5432/circle_test
- image: circleci/postgres:9.6.2 # an example of how to specify a service container
environment:
POSTGRES_USER: postgres
POSTGRES_DB: circle_test

Hey! Welcome to the community.

Can you help us understand what is happening in your tests when you run into this error?

Hey @levlaz sorry I took long on this

Here is my config file

defaults:
  working_directory: ~/incognita-django-env
  docker:
  - image: circleci/python:3.6.4
    environment:
      PIPENV_VENV_IN_PROJECT: true
      DATABASE_URL: postgres://postgres:postgres@localhost:5432/circle_test
  - image: circleci/postgres:9.6.2
    environment:
      POSTGRES_USER: postgres
      POSTGRES_DB: circle_test
version: 2
jobs:
  checkout:
    working_directory: ~/incognita-django-env
    docker:
    - image: circleci/python:3.6.4
      environment:
        PIPENV_VENV_IN_PROJECT: true
        DATABASE_URL: postgres://postgres:postgres@localhost:5432/circle_test
    - image: circleci/postgres:9.6.2
      environment:
        POSTGRES_USER: postgres
        POSTGRES_DB: circle_test
    steps:
    - checkout
    - restore_cache:
        keys:
        - v1-dependencies-{{ checksum "requirements.txt" }}
        - v1-dependencies-
    - run:
        name: Install dependencies
        command: |
          python3 -m venv venv
          . venv/bin/activate
          pip3 install pycodestyle
          pip3 install -r requirements.txt
    - save_cache:
        paths:
        - .venv
        key: v1-dependencies-{{ checksum "requirements.txt" }}
    - persist_to_workspace:
        root: ~/incognita-django-env
        paths: .
  test:
    working_directory: ~/incognita-django-env
    docker:
    - image: circleci/python:3.6.4
      environment:
        PIPENV_VENV_IN_PROJECT: true
        DATABASE_URL: postgres://postgres:postgres@localhost:5432/circle_test
    - image: circleci/postgres:9.6.2
      environment:
        POSTGRES_USER: postgres
        POSTGRES_DB: circle_test
    steps:
    - attach_workspace:
        at: ~/incognita-django-env
    - run:
        name: Wait for Python linter to run
        command: |
          . venv/bin/activate
          pycodestyle . --exclude=migrations,settings,.env,env,venv
    - run:
        name: Setup Code Climate test-reporter
        command: |
          curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter
          chmod +x ./cc-test-reporter
    - run:
        name: Run code coverage tests and submit coverage report to code climate
        command: |
          . venv/bin/activate
          ./cc-test-reporter before-build
          coverage run --source=incognita manage.py test --settings=incognita.settings.test
          coverage xml
          coverage report
          ./cc-test-reporter after-build --exit-code $?
    
workflows:
  version: 2
  pipeline:
    jobs:
    - checkout
    - test:
        requires:
        - checkout

I don’t have a ready answer for this, as I don’t do Python. However, there are a couple of ways you can debug this:

  • Get a post-build SSH session on the build server and debug it as if it were a local problem. CI build servers are pretty much a standard virtual server. There is some environmental thing that is upsetting your tests. Maybe you have a listener component that has run out of memory? However you would debug this on your laptop, do that on the server.
  • Convert your tests to run in Docker. When you are happy they run nicely, set that up on CircleCI as Docker-in-Docker. Not only are your projects more portable from a CI perspective - handy if you decide to self-host your CI in the future, say - but you can debug most of your CI problems locally.
1 Like

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