Due to some unexpected downtime with my current web host, and a bit of spare time on my hands, I thought I would give a go at configuring Drone to deploy to Cloudflare Pages.

A very basic description of Cloudflare Pages, is that it’s a platform that makes it easy to create and host websites whilst Cloudflare takes care of the more technical side of website hosting. For a more technical overview, take a look at the official documentation.

For my use case, as I use Hugo to generate all my static website files, I can just use Cloudflare Pages to host the content. With my domain name already proxying through Cloudflare, everything is now all handled in one place, and so far, it all just works.

So let’s cover off what’s needed to get Drone to deploy your Hugo (or static files) to Cloudflare Pages.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website.
• A Git repository:
  • Host your Hugo website’s code in a Gitea / Git repository.
• A working Drone instance:
  • Your Drone instance should be working correctly with your Gitea repository.
• A Cloudflare account:
  • Your Cloudflare account is running, and you have configured both a new Cloudflare Page and have a Cloudflare Workers API set up.

A Drone Build Step for Cloudflare Pages

This guide follows on from my previous post where I walk through setting up a full drone pipeline with Test, Staging and Production builds and deployments. To catch up have a look at Creating a Full Drone Pipeline with Gitea and Drone

The following is a step that will build static content located in /drone/src//. Deploy to a Cloudflare Page defined by , and a Drone secret called <CLOUDFLARE_API_TOKEN> containing a Cloudflare API token.

- name: Build Node.js
    image: node:latest
    commands: 
      - npm install npm@latest -g 
      - mkdir -p dist
      - cp -R /drone/src/<your static files location>/* dist/ 

  - name: Deploy to Cloudflare Pages
    image: node:latest
    environment:
      CLOUDFLARE_API_TOKEN:
        from_secret: CLOUDFLARE_API_TOKEN
    commands: 
      - npm install wrangler --save-dev  
      - cd /drone/src/dist/
      - npx wrangler pages deploy /drone/src/dist --project-name "<project>" --env production --branch main --commit-dirty=true

There are a number of Docker images out there using Wrangler to deploy to Cloudflare. Unfortunately they all seem to use the previous version of the Cloudflare API which will deprecated shortly. So I went down the route of building Wrangler and NodeJS directly.

Do get in touch if you find a more recent Docker image for me to try.

A Drone Pipeline for Cloudflare Pages

This is a direct copy of my current production build pipeline. This has added debugging information that I find useful whilst making changes.

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  branch: 
    - main 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose --debug 
      - ls -al /drone/src/hugo/public

  - name: Build Node.js
    image: node:latest
    commands:
      - ls -la /drone/src/
      - npm install npm@latest -g
      - pwd
      - mkdir -p dist
      - cp -R /drone/src/hugo/public/* dist/
      - ls -la dist/

  - name: Deploy to Cloudflare Pages
    image: node:latest
    environment:
      CLOUDFLARE_API_TOKEN:
        from_secret: CLOUDFLARE_API_TOKEN
    commands:
      - ls -la /drone/src/
      - npm install wrangler --save-dev 
      - npx wrangler --version
      - cd /drone/src/dist/
      - npx wrangler pages deploy /drone/src/dist --project-name "<project-name>" --env production --branch main --commit-message "Drone Production Build" --commit-dirty=true

Summary

Once deployed, a new Deployment will be available for you in your Cloudflare Pages area that can be accessed either by the temporary preview deployment domain or your preview alias project domain.

Once happy you can now set up a custom domain to point to the new Page.

Although a few extra steps than an existing Docker Cloudflare setup, this method does allow you to clearly see what’s going on and debug any issues should they happen.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Cloudflare Workers Gitea Drone Hugo

In my previous posts, I’ve covered how to set up Drone, Gitea and deploy a build to an FTP server. In this post, I’ll be covering how to configure a full pipeline to include:

• A continuous testing build on each commit to the Develop branch.
• An automated build to a staging environment on commit to the Main branch.
• A manual deployment to a production environment using the Promote function in Drone.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website locally.
• A Git repository:
  • Host your Hugo website’s code in a Gitea repository.
• A working Drone instance:
  • Your Drone instance should be working correctly with your Gitea repository.
• An FTP server
  • An FTP server configured with username and password, a valid user home directory and web content loaded from that location.

What is a Drone Pipeline?

In Drone, a pipeline refers to a sequence of steps and actions that are executed in a predefined order to build, test, and deploy software. It provides a structured and automated workflow for managing the different stages of the development process.

A pipeline in Drone is typically defined using a configuration file named ‘.drone.yml’. This file specifies the steps to be executed, the order in which they should run, and any required configurations or dependencies.

Here are the key components and concepts associated with a pipeline in Drone:

• Stages:
  A pipeline is divided into stages, which represent different phases of the software development lifecycle. Common stages include building, testing, and deploying. Each stage contains one or more steps that define the actions to be performed.

• Steps:
  Steps are the individual units of work within a stage. They represent specific actions to be executed, such as running a command, running tests, or deploying the application. Steps can be executed sequentially or in parallel, depending on the requirements.

• Dependencies:
  A step in a pipeline may have dependencies on previous steps. This allows for the establishment of a logical flow, where certain steps must be completed successfully before proceeding to the next ones. Dependencies ensure that the pipeline runs in a consistent and controlled manner.

• Conditions:
  Conditions are used to control the execution of steps based on specific criteria. For example, a step may only run if a certain condition is met, such as the branch name, the outcome of a previous step, or the presence of a specific environment variable. Conditions provide flexibility and allow for conditional execution based on the project’s needs.

• Artifacts:
  Artifacts are files or directories generated during the pipeline execution that can be passed between steps or stored for later use. They allow for sharing data, test reports, build artifacts, or any other relevant files between different stages of the pipeline.

• Triggers:
  Triggers determine when the pipeline should run. They can be defined to automatically start the pipeline on specific events, such as code pushes, pull requests, or scheduled intervals. Triggers ensure that the pipeline is executed whenever a relevant change occurs, maintaining an up-to-date and automated development process.

Development Build

In my current setup, every commit to the Develop branch is picked up by Drone and creates a build. This build pulls the develop branch from the Gitea repository, installs the Hugo modules and builds the Hugo website in development mode.

I have also set this to fail on any warnings, so that I can quickly see if there are any problems with my code.

This step is where I would run any tests on the output code and fail the build should any fail. More to come on that in future posts.

The specific steps for this in the drone.yaml file are:

---
kind: pipeline
type: docker
name: "Test Environment"

trigger:
  branch: 
    - develop 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      # Disable panicOnWarning due to bug in Hugo.
      - hugo --environment development --verbose --debug # --panicOnWarning
      - ls -al /drone/src/hugo/public

As you can see, every push to the ‘develop’ branch will trigger the following steps. I have this configured to also show debug and more verbose information to help with investigating any problems. You’ll see I also specify the development environment in Hugo, this is to prevent items such as Google Analytics from running in a test setup.

Staging Build

My staging build is run when a commit is made to the main branch. A nice approach would be to lock down the main branch so that no commits can be made directly to it. Any merges from the develop branch must come via a pull request. A tad overkill for a home setup, but it’s good practice.

This build will do the same as the Test build, but also includes a step to deploy to my staging web server.

---
kind: pipeline
type: docker
name: "Staging Environment"

trigger:
  branch:
    - main
  event:
    include: 
      - push

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment develop --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Staging FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: staging_ftp_username
        FTP_PASSWORD:
          from_secret: staging_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: staging_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: staging_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

You can see that I specify the environment for Hugo, as development. And this time, take advantage of Drone secrets for the Staging server details and credentials.

Production Build

Now the production build is slightly different, in that it can only be run through Drone by promoting an existing successful Staging build.

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  target: 
    - production

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Production FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: production_ftp_username
        FTP_PASSWORD:
          from_secret: production_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: production_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: production_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Here you’ll see that we change the environment for Hugo to be production and use Drone secrets again to specify the Production details and credentials.

Complete Drone Configuration

Putting all of these steps together, the complete config.yml file looks like this:

---
kind: pipeline
type: docker
name: "Test Environment"

trigger:
  branch: 
    - develop 
  event:
    include:
      - push

steps:   
  - name: Clone Git Submodules
    image: alpine/git 
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      # Disable panicOnWarning due to bug in Hugo.
      - hugo --environment development --verbose --debug # --panicOnWarning
      - ls -al /drone/src/hugo/public

---
kind: pipeline
type: docker
name: "Staging Environment"

trigger:
  branch:
    - main
  event:
    include: 
      - push

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment development --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Staging FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: staging_ftp_username
        FTP_PASSWORD:
          from_secret: staging_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: staging_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: staging_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

---
kind: pipeline
type: docker
name: "Production Environment"

trigger:
  target: 
    - production

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote

  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always 
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --environment production --verbose
      - ls -al /drone/src/hugo/public

  - name: Deploy to Production FTP
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
          from_secret: production_ftp_username
        FTP_PASSWORD:
          from_secret: production_ftp_password 
        PLUGIN_SECURE: true
        PLUGIN_VERIFY: true
        PLUGIN_HOSTNAME:
          from_secret: production_ftp_hostname
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: 
          from_secret: production_ftp_directory
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Summary

With the above setup, you can see how easily a full work flow can be configured in Drone that will enable automatic and continuous builds and deployments. Hopefully saving you some time in the future and catching any problems well before they reach the production environment.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

This is the setup that I’m using for both my staging website and my production one (This one!).

Hugo does come with a built-in server for viewing your site locally but having a staging site gives me more confidence that everything will work correctly when deployed to my main website, especially as the whole process is automated.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• A working Hugo website:
  • Set up a Hugo website locally.
• A Git repository:
  • Host your Hugo website’s code in a Git repository.
• An FTP server
  • An FTP server configured with username and password, a valid user home directory and web content loaded from that location.

Step 1: Configure the Drone.io Pipeline

1. In your websites Git repository, create a .drone.yml file in the root directory.
2. Add the following code to the .drone.yml file:

kind: pipeline
name: your-pipeline-name

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote
      
  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --verbose 
      - ls -al /drone/src/hugo/public 
      
  - name: Deploy to FTP server
    image: cschlosser/drone-ftps
    environment:
        FTP_USERNAME:
            from_secret: ftp_username
        FTP_PASSWORD:
            from_secret: ftp_password 
        PLUGIN_SECURE: false
        PLUGIN_VERIFY: false
        PLUGIN_HOSTNAME: ftp://host:21
        PLUGIN_SRC_DIR: /hugo/public/
        PLUGIN_DEST_DIR: /home/ftp_username
        PLUGIN_AUTO_CONFIRM: true
        PLUGIN_DEBUG: true 
        PLUGIN_ONLY_NEWER: true

Replace your-pipeline-name with a suitable name for your pipeline.

3. Adjust the PLUGIN_HOSTNAME and PLUGIN_DEST_DIR fields to match your remote server details and deployment directory.

4. Add secret for your remote server’s username and password by going to your Drone.io repository settings and adding secrets with the keys ftp_username, ftp_password and the corresponding values.

Step 2: Trigger the Pipeline

1. Push your updated .drone.yml file to your Git repository.
2. This will trigger the Drone.io pipeline to run.
3. Monitor the build process in the Drone.io interface to ensure everything is working correctly.
4. Once the pipeline completes successfully, your Hugo website will be deployed to the specified remote server.

You have successfully set up Drone with an FTP server. Now, whenever you push changes to your Git repository, Drone.io will automatically build your Hugo website and deploy it to your remote FTP server.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo

In this guide, I’ll walk you through the process of setting up Hugo with a Docker Drone.io container and GitHub, allowing you to streamline your website deployment workflow.

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

• Docker installed:
  • Ensure you have Docker installed on your local machine.
• Basic knowledge of Docker:
  • Familiarity with Docker and Docker Compose will be helpful.
• A working Hugo website:
  • Set up a Hugo website locally.
• A GitHub repository:
  • Host your Hugo website’s code in a GitHub repository.

Step 1: Set Up a Docker Drone.io Container

1. Create a new directory on your machine for the Docker Drone.io container configuration.
2. Create a docker-compose.yml file within that directory and add the following content:

version: '3'
services:
  drone-server:
    image: drone/drone:latest
    ports:
      - "8080:80"
    volumes:
      - ./drone-data:/data
    restart: always
    environment:
      - DRONE_GITHUB_CLIENT_ID=your-github-client-id
      - DRONE_GITHUB_CLIENT_SECRET=your-github-client-secret

  drone-runner:
    image: drone/drone-runner-docker:latest
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    restart: always

3. Save the file and navigate to the Docker Drone.io container configuration directory in your terminal.

4. Replace your-github-client-id and your-github-client-secret with the appropriate values. These can be obtained by registering a new OAuth application within GitHub’s settings.

5. Run the command docker-compose up -d to start the Docker Drone.io container.

Drone.io should now be accessible at http://localhost:8080.

Step 2: Connect Drone.io to GitHub

1. Open Drone.io in your web browser at http://localhost:8080.
2. Sign in with your GitHub credentials.
3. Authorise Drone.io to access your GitHub repositories.

Step 3: Configure the Drone.io Pipeline

1. Within your Hugo website’s GitHub repository, create a .drone.yml file in the root directory.
2. Add the following code to the .drone.yml file:

kind: pipeline
name: your-pipeline-name

steps:
  - name: Clone Git Submodules
    image: alpine/git
    commands:
      - git submodule init
      - git submodule update --recursive --remote
      
  - name: Build with Hugo
    image: binaryronin/drone-hugo:latest
    pull: always
    commands:
      - echo "Checking Hugo version."
      - hugo version
      - cd /drone/src/hugo/
      - hugo --verbose 
      - ls -al /drone/src/hugo/public 

  - name: Deploy
    image: appleboy/drone-scp
    settings:
      host: your-remote-host
      username: your-remote-username
      password:
        from_secret: your-remote-password-secret
      source: 
        - /hugo/public/
      target: /path/to/your/remote/directory

Replace your-pipeline-name with a suitable name for your pipeline.

3. Adjust the host, username, password, and target fields to match your remote server details and deployment directory.

4. Add a secret for your remote server’s password by going to your Drone.io repository settings and adding a secret with the key your-remote-password-secret and the corresponding value.

Step 4: Trigger the Pipeline

1. Push your updated .drone.yml file to your GitHub repository.
2. This will trigger the Drone.io pipeline to run.
3. Monitor the build process in the Drone.io interface to ensure everything is working correctly.
4. Once the pipeline completes successfully, your Hugo website will be deployed to the specified remote server.

You have successfully set up Hugo with a Docker Drone.io container and GitHub. Now, whenever you push changes to your GitHub repository, Drone.io will automatically build your Hugo website and deploy it to your remote server.

I’ll continue documenting my journey with Gitea, Drone and Hugo and share the interesting things I find along the way.

If you want to look further in to any of the above tools, do take a look at my previous posts and read the official documentation from the following sites:

Gitea Drone Hugo