Updated excerpts

This commit is contained in:
Oliver Davies 2015-07-21 18:10:34 +01:00
parent 86543cb33f
commit 73a0931377
3 changed files with 2 additions and 13 deletions

View file

@ -8,10 +8,6 @@ tags:
- github - github
- sculpin - sculpin
--- ---
{% block excerpt %}
I just had to update a repo that I forked on GitHub. This is how I did it. Did I do it the correct way?
{% endblock %}
{% block content %} {% block content %}
## Sculpin ## Sculpin

View file

@ -3,7 +3,7 @@ layout: post
title: Sculpin and Twig Resources title: Sculpin and Twig Resources
date: 2015-07-19 date: 2015-07-19
meta: meta:
description: Some links to useful resources relating to Sculpin. description: A compiled list of resources relating to Sculpin and Twig.
tags: tags:
- sculpin - sculpin
- drupalcamp - drupalcamp
@ -12,7 +12,7 @@ tags:
slug: sculpin-twig-resources slug: sculpin-twig-resources
--- ---
{% block excerpt %} {% block excerpt %}
A compiled list of resources relating to Sculpin and Twig. Heres a list of resources that I compiled whilst preparing for my [Sculpin and Twig talk](http://drupalcampnorth.org/session/test-drive-twig-sculpin) at [DrupalCamp North](http://drupalcampnorth.org).
{% endblock %} {% endblock %}
{% block content %} {% block content %}

View file

@ -7,12 +7,6 @@ tags:
- jenkins - jenkins
slug: automating-sculpin-jenkins slug: automating-sculpin-jenkins
--- ---
{% block excerpt %}
How to automate Sculpin builds via Jenkins, either periodically or when a Git commit is pushed.
{% endblock %}
{% block content %}
As part of re-building this site with [Sculpin](http://sculpin.io), I wanted to automate the deployments, as in I wouldn't need to run a script like [publish.sh](https://raw.githubusercontent.com/sculpin/sculpin-blog-skeleton/master/publish.sh) locally and have that deploy my code onto my server. Not only did that mean that my local workflow was simpler (update, commit and push, rather than update, commit, push and deploy), but if I wanted to make a quick edit or hotfix, I could log into GitHub or Bitbucket (wherever I decided to host the source code) from any computer or my phone, make the change and have it deployed for me. As part of re-building this site with [Sculpin](http://sculpin.io), I wanted to automate the deployments, as in I wouldn't need to run a script like [publish.sh](https://raw.githubusercontent.com/sculpin/sculpin-blog-skeleton/master/publish.sh) locally and have that deploy my code onto my server. Not only did that mean that my local workflow was simpler (update, commit and push, rather than update, commit, push and deploy), but if I wanted to make a quick edit or hotfix, I could log into GitHub or Bitbucket (wherever I decided to host the source code) from any computer or my phone, make the change and have it deployed for me.
I'd started using [Jenkins CI](http://jenkins-ci.org) during my time at the Drupal Association, and had since built my own Jenkins server to handle deployments of Drupal websites, so that was the logical choice to use. I'd started using [Jenkins CI](http://jenkins-ci.org) during my time at the Drupal Association, and had since built my own Jenkins server to handle deployments of Drupal websites, so that was the logical choice to use.
@ -94,4 +88,3 @@ I set this to `@daily` (the same `H H * * *` - `H` is a Jenkins thing), so that
This workflow works great for one site, but as I roll out more Sculpin sites, I'd like to reduce duplication. I see this mainly as Ill end up creating a separate `sculpin_build` item thats decoupled from the site that its building, and instead passing variables such as environment, server name and docroot path as parameters in a parameterized build. This workflow works great for one site, but as I roll out more Sculpin sites, I'd like to reduce duplication. I see this mainly as Ill end up creating a separate `sculpin_build` item thats decoupled from the site that its building, and instead passing variables such as environment, server name and docroot path as parameters in a parameterized build.
I'll probably also take the raw shell script out of Jenkins and save it in a text file that's stored locally on the server, and execute that via Jenkins. This means that Id be able to store this file in a separate Git repository with my other Jenkins scripts and get the standard advantages of using version control. I'll probably also take the raw shell script out of Jenkins and save it in a text file that's stored locally on the server, and execute that via Jenkins. This means that Id be able to store this file in a separate Git repository with my other Jenkins scripts and get the standard advantages of using version control.
{% endblock %}