https://github.com/LuisGC/blog
Tip revision: a1e59c02bcceca014aea0af30ef8e47c840ed888 authored by Luis GarcĂa Castro on 18 July 2024, 15:43:06 UTC
Merge pull request #40 from LuisGC/japon-2023
Merge pull request #40 from LuisGC/japon-2023
Tip revision: a1e59c0
config.yml
# 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