It does! There are several sort of 'catch-alls' in place:

1) stuff in /etc that doesn't belong to any obvious package, ends up in an 'etc_custom' role

2) stuff in /usr/local ends up in a 'usr_local_custom' role

3) Anything you include with --include will end up in a special 'extra_paths' role.

Here's a demo (which is good, helped me spot a small bug, the role is included twice in the playbook :) I'll get that fixed!) https://asciinema.org/a/765385

Thanks for your interest!

▲

indigodaddy 3 days ago | parent | next [-]

Also, enroll.sh could be VERY useful for vibe-coding. git tracking will only capture application-level (unless you are fully dockerizing the app), however, for example if you are done vibe-coding your app, point enroll.sh at the VM or whatever you are using (this is assuming you are vibe-coding to a Linux system/VM/instance with ssh available), and you can then capture both application and system level needs, and have an Ansible playbook that you can deploy anywhere at the end of it. Eg, I told the folks on exe.dev that enroll.sh would be very useful for a service like exe.dev.

	▲	_mig5 3 days ago \| parent [-]
		Cool tool, didn't know it existed! :) Thanks for passing on the word. 'Capture app and system stuff and deploy anywhere' is totally the goal :)

▲

indigodaddy 6 days ago | parent | prev [-]

Nuts, I'm going to have to try this out. Pretty sure nothing like this exists, at least not for Ansible (?). This would certainly help converting chef cookbooks (we have a ton of custom applications along with system stuff of course) to Ansible (I guess it's not really converting in this scenario, just scanning the host(s), super neat!). We are still using chef, and use Ansible for one-off jobs/playbooks/remediations etc, but would like to pivot to Ansible for config mgmt of everything for deployments at some point. This definitely looks useful in that effort.