add provisioning-hooks directory to operate like deploy-hooks

[nbyloff]

Submit a feature request or bug report

• I've read the guidelines for Contributing to Roots Projects
• This is a feature request
• This request isn't a duplicate of an existing issue
• I've read the docs and followed them (if applicable)
• This is not a personal support request that should be posted on the Roots Discourse forums

Replace any X with your information.

---

What is the current behavior?

Any custom roles/tasks needed during provisioning must be added to the main server.yml, causing conflicts between projects and the trellis base when trying to keep it in sync locally.

What is the expected or desired behavior?

I think it would be a nice feature to just add custom.yml files to a directory that get automatically run during provisioning. So when merging the main trellis base into local projects, custom provisioning additions won't be lost when updating things like the main server.yml file.

---

Feature Request

Please provide use cases for changing the current behavior:

In my example, I always add a custom backup job that zips and pushes the DB and uploads directory to an Amazon s3 bucket nightly.

Other relevant information:

Added this task to the end of the server.yml

---
- name: read custom provisioning hooks
  find:
    paths: "custom-roles"
    patterns: "*.yml"
  register: custom_tasks

- name: execute custom provisioning hooks
  include: "{{ item.path }}"
  with_items: "{{ custom_tasks.files }}"

Creating a custom-roles folder and dropped two YAML files in there. They executed with no errors. Something like that built in would help guys like me from shooting themselves in the foot.

[swalkinshaw]

I'm not sure about this. For one thing, roles depend on order. The ugly solution to that is people naming roles like 1-whatever which is not cool 😔

One goal of Trellis is to still expose Ansible. I think it's important for people to understand the basic playbooks and this abstracts that away a little bit too.

[nbyloff]

That could be ugly, a bunch of numbered files. But that's left to people's dev patterns too. Personally, I would create a custom-main.yml in that folder, and have a bunch of sub-folders that have each of my roles and custom-main.yml has all my tasks ordered appropriately. Just an extension of how server.yml works. But if I only had a couple extra tasks, I might just put them all in the custom-main.yml. I suppose some may not like that either, but it would do wonders for maintenance on customized client environments.

The abstraction can also be good too, especially as the user base matures and understands Ansible more. My impression would be that the users who intend on adding customizations to Trellis have some understanding of how Ansible works. In order for someone to use the provision-hooks task, they'd have to. The trellis documentation is already really good so with a couple extra paragraphs for provision-hooks I think that's sufficient for most users. It could even contain a couple commented out examples like in the deploy-hooks folder.

[strarsis]

Numbered files (for ordering) are often used in configs in distributions like Debian/Ubuntu but also
in Docker config folders. I actually like this pattern, it also makes pulling from Trellis master much easier.

[nbyloff]

I see this is still not dead, but discussion stopped. This would be huge for me. Here's my input:

• With the example code, a user can introduce new code in multiple ways. They could (1) have a single YAML file that references other YAML files (or complete roles) in the order they should be executed, (2) number the files like suggested in order of execution.
• I think this would actually encourage people to understand ansible and trellis more. I would imagine in most scenarios, once you're to the point you want to add custom functionality to provisioning, you have basic understanding of how things are working.
• Merging into your project from trellis master become a lot less painful (this cannot be understated how nice it will be)

[swalkinshaw]

This just isn't on our list of priorities right now but if you want to do the work and put up a PR, then it could potentially move it along. I can't guarantee it would get merged though as I haven't thought much about it lately.

[nbyloff]

I'll make a PR for this for sure; it will be 100% optional and only available as people might need it.

[swalkinshaw]

See #882