# This configuration was automatically generated from a CircleCI 1.0 config. # It should include any build commands you had along with commands that CircleCI # inferred from your project structure. We strongly recommend you read all the # comments in this file to understand the structure of CircleCI 2.0, as the idiom # for configuration has changed substantially in 2.0 to allow arbitrary jobs rather # than the prescribed lifecycle of 1.0. In general, we recommend using this generated # configuration as a reference rather than using it in production, though in most # cases it should duplicate the execution of your original 1.0 config. version: 2 jobs: build: working_directory: ~/LuisGC/blog parallelism: 1 shell: /bin/bash --login # CircleCI 2.0 does not support environment variables that refer to each other the same way as 1.0 did. # If any of these refer to each other, rewrite them so that they don't or see https://circleci.com/docs/2.0/env-vars/#interpolating-environment-variables-to-set-other-environment-variables . environment: CIRCLE_ARTIFACTS: /tmp/circleci-artifacts CIRCLE_TEST_REPORTS: /tmp/circleci-test-results BASE_URL: https://luiyo.net HUGO_OUTPUT_FOLDER: docs # In CircleCI 1.0 we used a pre-configured image with a large number of languages and other packages. # In CircleCI 2.0 you can now specify your own image, or use one of our pre-configured images. # The following configuration line tells CircleCI to use the specified docker image as the runtime environment for you job. # We have selected a pre-built image that mirrors the build environment we use on # the 1.0 platform, but we recommend you choose an image more tailored to the needs # of each job. For more information on choosing an image (or alternatively using a # VM instead of a container) see https://circleci.com/docs/2.0/executor-types/ # To see the list of pre-built images that CircleCI provides for most common languages see # https://circleci.com/docs/2.0/circleci-images/ docker: # https://hub.docker.com/r/cibuilds/hugo/tags - image: cibuilds/hugo:0.99.1 steps: # Machine Setup # If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each # The following `checkout` command checks out your code to your working directory. In 1.0 we did this implicitly. In 2.0 you can choose where in the course of a job your code should be checked out. - checkout # Checking out the submodules as well - run: name: "Pull Submodules" command: | git submodule init git submodule update --remote # Prepare for artifact and test results collection equivalent to how it was done on 1.0. # In many cases you can simplify this from what is generated here. # 'See docs on artifact collection here https://circleci.com/docs/2.0/artifacts/' # - run: mkdir -p $CIRCLE_ARTIFACTS $CIRCLE_TEST_REPORTS # This is based on your 1.0 configuration file or project settings - run: command: git config --global user.name "CircleCI" - run: command: git config --global user.email "circleci@circleci.com" # Dependencies # This would typically go in either a build or a build-and-test job when using workflows # Restore the dependency cache - restore_cache: keys: # This branch if available - v1-dep-{{ .Branch }}- # Default branch if not - v1-dep-master- # Any branch if there are none on the default branch - this should be unnecessary if you have your default branch configured correctly - v1-dep- - run: name: "Checking Hugo version" command: hugo version - run: name: "Build Website With Hugo" command: hugo -v -d ${HUGO_OUTPUT_FOLDER} --cleanDestinationDir --baseUrl=${BASE_URL} # Save dependency cache - save_cache: key: v1-dep-{{ .Branch }}-{{ epoch }} paths: # This is a broad list of cache paths to include many possible development environments # You can probably delete some of these entries - vendor/bundle # - ~/virtualenvs # - ~/.m2 # - ~/.ivy2 # - ~/.bundle # - ~/.go_workspace # - ~/.gradle # - ~/.cache/bower # Test # This would typically be a build job when using workflows, possibly combined with build # This is based on your 1.0 configuration file or project settings # - run: hugo check # Deployment # Your existing circle.yml file contains deployment steps. # The config translation tool does not support translating deployment steps # since deployment in CircleCI 2.0 are better handled through workflows. # See the documentation for more information https://circleci.com/docs/2.0/workflows/ # Teardown # If you break your build into multiple jobs with workflows, you will probably want to do the parts of this that are relevant in each # Save test results # - store_test_results: # path: /tmp/circleci-test-results # Save artifacts # - store_artifacts: # path: /tmp/circleci-artifacts # - store_artifacts: # path: /tmp/circleci-test-results - run: name: Deploy static pages to Github Pages command: | if [ "${CIRCLE_BRANCH}" = "master" ]; then echo -e "Starting to deploy to Github Pages\n" cd ~/LuisGC/blog # using token clone gh-pages branch git clone --quiet --branch=$CIRCLE_BRANCH https://${GH_TOKEN}@github.com/$TARGET_REPO built_website > /dev/null # go into directory and copy data we're interested in to that directory cd built_website echo "installing rsync..." apt-get -y install rsync echo "rsync built code with checked out code..." rsync -r --exclude=.git --exclude=CNAME --exclude=LICENSE --exclude=README.md ../$HUGO_OUTPUT_FOLDER/ . echo "add files to git..." git add -f . echo "commit files to git repository..." if git commit -m "CircleCI build $CIRCLE_BUILD_NUM on $(date) pushed to Github Pages" ; then echo "git push files with force..." git push -fq origin master > /dev/null echo -e "Deploy completed\n" else echo "Content not changed, nothing to deploy" fi else echo "Not master branch, dry run only" fi