opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues 1 Pull requests Projects 1 Releases Packages Wiki Activity Actions

Make all links relative

Browse source 
Now the abs_to_rel module is enabled, links can be made relative so they
work on the current environment.
This commit is contained in:
Oliver Davies 2025-05-29 16:42:25 +01:00
parent 0d359f81d6
commit 7a7dc297ca
349 changed files with 698 additions and 698 deletions
Download patch file Download diff file Expand all files Collapse all files

4
content/node.41b8a70d-5df8-45f5-956a-c30b2f3e06de.json
View file

@ -82,9 +82,9 @@
],
"body": [
{
"value": "\n <p>As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.<\/p>\n\n<p>Some only run continuous integration checks, like automated tests and static analysis, some build and push Docker images, and some use Ansible and Ansistrano to deploy the changes to production.<\/p>\n\n<p>Each tool has its configuration file with different settings and formats.<\/p>\n\n<p>Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and <a href=\"https:\/\/www.oliverdavies.uk\/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">use a run file<\/a> with separate <code>ci:build<\/code> and <code>ci:deploy<\/code> tasks.<\/p>\n\n<p>This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.<\/p>\n\n ",
"value": "\n <p>As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.<\/p>\n\n<p>Some only run continuous integration checks, like automated tests and static analysis, some build and push Docker images, and some use Ansible and Ansistrano to deploy the changes to production.<\/p>\n\n<p>Each tool has its configuration file with different settings and formats.<\/p>\n\n<p>Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and <a href=\"/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">use a run file<\/a> with separate <code>ci:build<\/code> and <code>ci:deploy<\/code> tasks.<\/p>\n\n<p>This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.<\/p>\n\n ",
"format": "full_html",
"processed": "\n <p>As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.<\/p>\n\n<p>Some only run continuous integration checks, like automated tests and static analysis, some build and push Docker images, and some use Ansible and Ansistrano to deploy the changes to production.<\/p>\n\n<p>Each tool has its configuration file with different settings and formats.<\/p>\n\n<p>Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and <a href=\"https:\/\/www.oliverdavies.uk\/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">use a run file<\/a> with separate <code>ci:build<\/code> and <code>ci:deploy<\/code> tasks.<\/p>\n\n<p>This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.<\/p>\n\n ",
"processed": "\n <p>As I work on various projects, I use several different CI tools, such as GitHub Actions, Bitbucket Pipelines, and GitLab CI, as well as hosting providers that have build and deploy steps.<\/p>\n\n<p>Some only run continuous integration checks, like automated tests and static analysis, some build and push Docker images, and some use Ansible and Ansistrano to deploy the changes to production.<\/p>\n\n<p>Each tool has its configuration file with different settings and formats.<\/p>\n\n<p>Rather than being too tightly coupled to a particular tool, I like to keep things as agnostic as possible and <a href=\"/daily\/2022\/08\/15\/using-run-file-simplify-project-tasks\">use a run file<\/a> with separate <code>ci:build<\/code> and <code>ci:deploy<\/code> tasks.<\/p>\n\n<p>This means that all the logic is within the run file rather than the CI tool-specific configuration file, so the file is shorter and cleaner; I can make changes to the CI tasks locally and quickly test changes and iterate, and also, as the logic is within the run file, I can easily switch to a different CI tool if needed without making changes to the tasks themselves.<\/p>\n\n ",
"summary": null
}
],