Codependent Codr is my personal tech blog where I braindump things I've learned, tips, tricks and ideas around full-stack development. The site can be found at https://www.codependentcodr.com
The site is generated using Pelican, and hosted in AWS. Currently it's a static site in an S3 bucket, served via AWS Cloudfront.
By in large I just ran the pelican-quickstart and have tweaked a few things here and there as I work on the site.
At this point my Makefile has been largely rewritten. Some of the things I've changed/added/done that might be
novel:
Being a Visual Studio Code user, I created a tasks.json file which has a
handful of tasks for things like starting the dev server, uploading to S3, etc.
Currently I use Github Actions for my CI/CD needs. Merges to the mainline
branch are automatically deployed to S3 by GH Actions. Pull requests are
automatically built with a number of checks (mostly linters) and builds are
"failed" on non-zero exit codes.
On a deployment to S3 I automagically tag the current commit with a generated tag that includes the current date/time, the milliseconds since the epoch, and the Git SHA. This means that I can look at the tags page on Github to see a history of deployments.
As well, I throw a notification into a private Slack channel when a deployment happens. This probably is silly right now (since I'm the only person deploying), but was fun to set up. :) This was set up as a basic Slack incoming webhook. The secret token on the URL I have in an environment variable.
Lastly, when GH Actions does a build it produces a Docker image and does the deployment from a running instance of that Docker image. After successful deployment that Docker image is uploaded to Docker Hub. This allows me to see exactly what was deployed, including for old deployments.
In the Makefile I added targets for running markdownlint and
pylint, and 'pydocstyle'.
This allows me to run linters over the repository before any deployment. I currently have a zero-tolerance
policy for linting errors (ie linters must run clean before code can be merged into the mainline branch).
Config for the markdown linter is in .markdownlint.json. For the most part I just added exceptions that were
needed so that Pelican's metadata didn't trigger markdownlint warnings.
For Pylint I don't use any special config (just default out of the box config).
For Pydocstyle, config is in .pydocstyle, which currently excludes the rather noisy D401 warning, as well
as excludes the theme directory from analysis.
To support the linting stuff, rather than enforcing I have the tools installed, I create a Docker image & install
the tools to it. This means if you want to do the same all you need is Docker, no need for npm, etc.
The clean target of the Makefile also removes any previously built codependentcodr images.
Originally everything was specified in the Dockerfile in this repo, however I found that led to long build times. I ended up refactoring the Dockerfile to have a Dockerfile in a separate repo (see https://github.com/pzelnip/codependentcodrbase) which contains some basic 3rd party dependencies (npm, git, etc) and is built nightly. This repo then uses the latest version of that Docker image as its base image. This helps with build times.
I also have a Makefile target to run the Safety tool for checking any Python dependencies I have for security vulnerabilities. This is also enforced by my CI pipeline (no merges if vulnerability found).
For the record, this actually now happens on the codependentcodrbase image rather than in this repo.
Instead of s3cmd (which is what the generated Makefile uses), I changed to use the
AWS CLI because A) it's better, and B) I already had it installed.
I hacked together some stuff in pelicanconf.py to get the git SHA & throw it into a variable. This
is then displayed in the page footer, which I find useful for coherence checking what revision is running.
Flex (the theme I use) has support for Github Corners,
but the colour isn't configurable. I modified the theme to use a config value GITHUB_CORNER_BG_COLOR
which sets the background colour of the github corners icon (in my config I set it to the same value
as the BG colour of buttons from the theme).
As mentioned, I have the site set up in AWS. All the generated content goes into a S3 bucket, and then I have a Cloudfront distribution in front of that. I pretty much only have CF for the purposes of getting an SSL cert in place (I doubt I have many readers around the world, so not like I need a CDN). The cert is from AWS Certificate Manager. Unlike most tutorials (and probably to my detriment), I don't manage DNS with Route 53, but instead through the registrar I purchased the domain from (https://namecheap.com).