Skip to content

Instantly share code, notes, and snippets.

@Bhavdip

Bhavdip/ReadMe1.md

Last active December 23, 2017 06:53
Show Gist options
  • Save Bhavdip/e7d9e13f487a25660515c686f58872a1 to your computer and use it in GitHub Desktop.
Save Bhavdip/e7d9e13f487a25660515c686f58872a1 to your computer and use it in GitHub Desktop.
Download ZIP
CircleCI Php
Raw
ReadMe1.md

Docker/Images/Machine

http://circleci.com/docs/2.0/circleci-images/ https://circleci.com/docs/2.0/build/#nav-button

Chossing your Executor Type

https://circleci.com/docs/2.0/executor-types/

This version of CircleCI enables you to run jobs in one of three environments: using Docker images, using a dedicated Linux VM image, or using a macOS VM image.

For building on Linux, there are tradeoffs to docker versus machine, as follows:

Using Docker

The docker key defines Docker as the underlying technology to run your jobs using Docker Containers. Containers are an instance of the Docker Image you specify and the first image listed in your configuration is the primary container image in which all steps run.

Docker increases performance by building only what is required for your application. Specify a Docker image in your .circleci/config.yml file that will generate the primary container where all steps run:

jobs:
  build:
    docker:
      - image: buildpack-deps:trusty

In this example, all steps run in the container created by the first image listed under the build job. To make the transition easy, CircleCI maintains convenience images on Docker Hub for popular languages

Using Machine

The machine option will run your jobs in a dedicated, ephemeral Virtual Machine (VM). Note: Use of machine may require additional fees in a future pricing update. To use the machine executor with the default machine image, set the machine key to true in .circleci/config.yml:

jobs:
  build:
    machine: true

Using the machine executor enables your application with full access to OS resources and provides you with full control over the job environment, if for example, you need to use ping or to modify system with sysctl commands. In addition, it enables your repo to build a docker image without additional downloads for languages like Ruby and PHP.

Jobs and Steps

The following section provide a overview of jobs and steps, changes to keys from 1.0 and new keys are nested Steps and new keys for workflows:

Jobs are a collection of steps. All the steps in the job are executed in a single until which consumes a Circle CI container from your plan its running.

In 2.0 Jobs can be run using machine executor which enables reuse of recently used machine executor runs, or the docker executor which can compose Docker containers to run your tests and any services they require, such as databases, or the macos executor

Steps Overview

Steps are a collection of executable command which are running a job, the checkout: key is required to checkout your code and a key for run: enables addition of arbitrary, multi-line shell command scripting

Sample Configuration with Parallel Jobs

Following is a sample 2.0 .circleci/config.yml file.

version: 2
jobs:
  build:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
  test:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

This example shows a parallel job workflow where the build and test jobs run in parallel to save time.

WorkFlows

Workflow is set of rules for defining a collection of jobs and their run order that shortens feedback loop. We can run the job in sequence or parallel.

Workflows Configuration:

To run a set of parallel jobs, add a new workflows: section to the end of your existing .circleci/config.yml file with the version and a unique name for the workflow. The following sample .circleci/config.yml file shows the default workflow orchestration with two parallel jobs. It is defined by using the workflows: key named build_and_test and by nesting the jobs: key with a list of job names.

The jobs have no dependencies defined, therefore they will run in parallel.

version: 2
jobs:
  build:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
  test:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

Sequential Job Execution Example:

The following example shows a workflow with four sequential jobs. The jobs run according to configured requirements, each job waiting to start until the required job finishes successfully as illustrated in the diagram.

The following config.yml snippet is an example of a workflow configured for sequential job execution:

workflows:
  version: 2
  build-test-and-deploy:
    jobs:
      - build
      - test1:
          requires:
            - build
      - test2:
          requires:
            - test1
      - deploy:
          requires:
            - test2

The dependencies are defined by setting the requires: key as shown. The deploy: job will not run until the build and test1 and test2 jobs complete successfully. A job must wait until all upstream jobs in the dependency graph have run. So, the deploy job waits for the test2 job, the test2 job waits for the test1 job and the test1 job waits for the build job.

Raw
ReadMe2.md

Deployment Overview

It is possible to deploy to any service by adding commands to .circleci/config.yml and setting secrets on the Project Settings > Environment Variables page of the CircleCI application.

Available deployment targets include Azure, Google (App Engine, Container Engine, and Cloud) and many others.

Add a job to your config.yml to set up conditional deployment for your application.The following example uses a workflow job filter to check that the current branch is the master branch before running any deploy commands. Without this workflow configuration, would be executed every time this job is triggered.


version: 2
jobs:
  build-job:
    docker:
      - image: my-image
    working_directory: /tmp/my-project
    steps:
      - run: <do-some-stuff>
            
  deploy-job:
    docker:
      - image: my-image
    working_directory: /tmp/my-project  
    steps:
      - run:
          name: Install some stuff
          command: <do-some-stuff>
      - run:
          name: Deploy if tests pass and branch is Master
          command: <my-deploy-commands>

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

https://circleci.com/docs/2.0/deployment_integrations/

Heroku

The built-in Heroku integration through the CircleCI UI is not implemented for CircleCI 2.0. However, it is possible to deploy to Heroku manually by using a script to set up Heroku, adding SSH keys with the add_ssh_keys option and configuring a workflow.

1.Create a script to set up Heroku similar to this example setup-heroku.sh file in the .circleci folder:


#!/bin/bash
  wget https://cli-assets.heroku.com/branches/stable/heroku-linux-amd64.tar.gz
  sudo mkdir -p /usr/local/lib /usr/local/bin
  sudo tar -xvzf heroku-linux-amd64.tar.gz -C /usr/local/lib
  sudo ln -s /usr/local/lib/heroku/bin/heroku /usr/local/bin/heroku

  cat > ~/.netrc << EOF
  machine api.heroku.com
    login $HEROKU_LOGIN
    password $HEROKU_API_KEY
  EOF

  cat >> ~/.ssh/config << EOF
  VerifyHostKeyDNS yes
  StrictHostKeyChecking no
  EOF

3.Create a new SSH key, without a passphrase, to connect to the Heroku Git server from CircleCI. The private key is added through the SSH Permissions page with a hostname of git.heroku.com as shown in the following screenshot:

4.Note down the Fingerprint for the private key for later reference.

6.Add a job with run steps and a workflow section similar to the following example in your config.yml file:


  deploy-job:
    docker:
      - image: my-image
    working_directory: /tmp/my-project  
    steps:
      - run:
          name: Run setup script
          command: bash .circleci/setup-heroku.sh
      - add_ssh_keys:
          fingerprints:
            - "48:a0:87:54:ca:75:32:12:c6:9e:a2:77:a4:7a:08:a4"
      - run:
          name: Deploy Master to Heroku
          command: |
            git push --force [email protected]:$HEROKU_APP_NAME.git HEAD:refs/heads/master
            heroku run python manage.py deploy
            heroku restart
               
 workflows:
   version: 2
   build-deploy:
     jobs:
       - build-job
       - deploy-job:
           requires:
             - build-job
           filters:
             branches:
               only: master

Notes:

  • The new run: step executes the setup-heroku.sh script
  • The add_ssh_keys: adds an SSH key to this build, which it gets from your CircleCI account based on the fingerprint you provide.
  • The workflow section filters on master and runs the Heroku deployment commands with every successful build on the master branch.
  • The heroku run commands should be changed to whatever steps make sense for the framework you use. For example, you may need to run rails db:migrate.

https://circleci.com/docs/1.0/permissions-and-access-during-deployment/

https://documentation.codeship.com/basic/continuous-deployment/deployment-with-ftp-sftp-scp/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment