[Best practices] Extend an occupied hook

It doesn’t seem to be possible using an ansible list for a hook file path.

I want to extend the deploy_build_after hook file, adding new functionality while preserving the original one (from Trellis). I want to avoid editing the file directly for better pulling+merging further Trellis updates (I use trellis as normal git repository and pull from GitHub).

There really isn’t one right now unfortunately. Which kind of defeats the purpose of hooks a bit :frowning:

We might be able to use Jinja inheritance for them. Want to create an issue for this?

I haven’t tried, but how about overriding deploy_build_after with your own include?

# deploy.yml
- deploy_build_after: "{{ playbook_dir }}/roles/deploy/hooks/build-after.yml"
+ deploy_build_after: "{{ playbook_dir }}/deploy-hooks/build-after.yml"

Then in your custom build-after.yml, just include the original

# deploy-hooks/build-after.yml

- name: some task
  command: stuff

# original tasks
- include: "{{ playbook_dir }}/roles/deploy/hooks/build-after.yml"

- name: some task
  command: more stuff

Created a new issue: https://github.com/roots/trellis/issues/814

That would be good, but it doesn’t seem to work, does it? In my test deployment just stopped before doing the build_after stuff, no error message or so.

@mockey Thanks for trying and reporting back. Trying just now, I get the same result. It’s baffling that the play just stops with no errors.

I think a “task include” parses and loads things a little differently than regular and has a problem with the usage of a default containing a quoted string. Here’s an example of changes Trellis might make to enable the nested include strategy above to succeed.

Remove this default . . .

# roles/deploy/tasks/build.yml
- - include: "{{ deploy_build_after | default('../hooks/example.yml') }}"
+ - include: "{{ deploy_build_after }}"

. . . placing the default in roles/deploy/defaults/main.yml instead:

# roles/deploy/defaults/main.yml
+ deploy_build_after: ../hooks/example.yml

There may be something Ansible needs to fix upstream, but perhaps Trellis could make this implementation adjustment for all deploy hooks in order to facilitate nested includes.

Yes, this whole include stuff seems a bit weird to me in Ansible.

It’s pretty cool that you figured that out, might really make sense to implement it this way.

Wouldn’t this be then an issue in ansible?

A fix proposed to Ansible upstream in ansible/ansible#23202