Forem: fuzzy_windfall

Using Circle CI and AWS S3 to Store Images in Hugo

fuzzy_windfall — Mon, 16 Nov 2020 16:40:00 +0000

Considering now that the blog has cover images to adhere with the design of the theme (also with the old theme), the number of images are getting larger including the repository itself. I've since removed the images from the repository and stored them on AWS S3.

The idea behind is to sync the images from the local filesystem to a bucket in S3, copy the files from the bucket over to a Circle CI workspace which contains the build files of Hugo, and finally deploy the build files to Netlify.

Sync'ing the Images

I've created first a bucket on S3 to store the images for the blog. In order to sync the images from the local filesystem, I have installed and configured AWS CLI:

$ brew install awscli
$ aws configure

Configuration is pretty much straightforward. I think all I needed to do was set the API keys and the region to where to store the images from. Permission was a bit confusing as I haven't used AWS much although I've set it to private since its purpose is only to store the images — Netlify will be the one actually hosting the images.

After configuring, I've used aws sync to sync the files from local filesystem to the bucket:

$ aws s3 sync . s3://path-to-bucket/

Copy Files Using Circle CI on Deployment

I've used the orb aws-s3 for Circle CI and added a job images to do the execution. The files are then persisted to a workspace. The build job is the one responsible for building Hugo and so I've attached the workspace over to this job and finally copied the files over to “content/images”. The images job is also a dependency for the build job.

orbs:
# The rest of the orbs.
hugo: circleci/hugo@0
aws-s3: circleci/aws-s3@1
version: 2.1
jobs:
images:
docker:
- image: circleci/python:2.7
steps:
- aws-s3/copy:
from: 's3://path-to-bucket'
to: images
arguments: --recursive
- persist_to_workspace:
root: .
paths:
- images
build:
docker:
- image: cibuilds/hugo:latest
steps:
- attach_workspace:
at: ~/images
- checkout
- run: cp -r ~/images/images/* content/images
# The rest of the steps.
workflows:
main:
jobs:
- images
- build:
requires:
- images
# The rest of the jobs.

The required environment variables to configure the aws-s3 orb are the following:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_REGION

These can be configured through Circle CI under Project Settings » Build Settings » Environment Variables.

Project Settings

So far, that is it. I just removed the images from the repository and added a .gitignore file to ignore the images under “content/images”.

I still need to include the static images though but will probably do it sometime in the future.

Debugging Drupal in Lando using (Neo)vim and Vdebug

fuzzy_windfall — Mon, 16 Nov 2020 03:06:31 +0000

With the introduction of OOP on Drupal 8, it has become a bit difficult for me to track how Drupal processes each request. Most of the time, you’ll be dealing with different objects, track down which class were instantiated and methods that were called, and inspect the variables.

Tools

So what are the tools that I am using? I’ve been a long time user of vim and recently just switched to Neovim. For development environment, I mostly jump between different methods for building Drupal but recently been using Lando.

Lando

For the configuration, simply setting xdebug to true so that Lando would enable xdebug in the environment:

name: drupal
recipe: drupal8
services:
appserver:
webroot: web
xdebug: true
config:
php: config/php.ini

For config/php.ini, I simply followed the one from setting up vscode:

[PHP]
; Xdebug
xdebug.max_nesting_level = 256
xdebug.show_exception_trace = 0
xdebug.collect_params = 0
; Extra custom Xdebug setting for debug to work in VSCode.
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.remote_host = ${LANDO_HOST_IP}
; xdebug.remote_connect_back = 1
xdebug.remote_log = /tmp/xdebug.log

(Neo)vim

For (Neo)vim, Vdebug seems to be the only option for using Xdebug in PHP. A minimal configuration can be:

call plug#begin(stdpath('data') . '/plugged')
Plug 'vim-vdebug/vdebug'
call plug#end()
if !exists('g:vdebug_options')
let g:vdebug_options = {}
endif
let g:vdebug_options.path_maps = {
\ '/app' : getcwd(),
\ }
let g:vdebug_options.break_on_open = 0
let g:vdebug_options.watch_window_style = 'compact'
if !exists('g:vdebug_features')
let g:vdebug_features = {}
endif
let g:vdebug_features.max_children = 128

vdebug_options.path_maps sets the paths so that it works with Lando.

vdebug_features.max_children allows inspecting variables from Drupal most of the time.

For other options, they can be found on :h Vdebug.

Debugging

Consider the scenario where you are viewing a node and wanted to debug the method \Drupal\node\Entity\Node::getType(). To start debugging, open the file core/modules/node/src/Entity/Node.php and set a breakpoint using F10, start the debugger using F5, and finally visit the a single node.

I’m not entirely sure of the actual definitions for step debugging although in my own words, I can probably explain them like these:

Step over: continue to the next line in the source.
Step into: if the line calls a certain function/method, then go over to that function/method where you can then continue debugging.
Step out: skip the remaining lines and proceed to the next step.

Bindings

From the configuration above, it mostly just relies on the default bindings (:h VdebugKeys):

let g:vdebug_keymap = {
\ "run" : "<F5>",
\ "run_to_cursor" : "<F9>",
\ "step_over" : "<F2>",
\ "step_into" : "<F3>",
\ "step_out" : "<F4>",
\ "close" : "<F6>",
\ "detach" : "<F7>",
\ "set_breakpoint" : "<F10>",
\ "get_context" : "<F11>",
\ "eval_under_cursor" : "<F12>",
\ "eval_visual" : "<Leader>e",
\}

User interface

Vdebug UI

The explanation for each window can be found at :h VdebugUI. I find the “Watch” window very helpful since I can inspect the different variables with their context. Pressing Enter on a variable would expand/collapse their trees.

So far, I think these are the basic things to debugging with (Neo)vim using Vdebug. Vdebug has a lot of other features such as evaluating although I haven’t gone much further with the other features yet.