# Ansible Workflow with Roles as Git Submodules **URL:** \ **Category:** Ansible Project\ **Created:** [August 15, 2014, 5:30am UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954 "2014-08-15T05:30:32Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Steffen\_Prince](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@Steffen\_Prince](https://forum.ansible.com/u/Steffen_Prince)\ **Post date:** [August 15, 2014, 5:30am UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954/1 "2014-08-15T05:30:32Z")
What are people’s experiences with using git submodules to incorporate reusable roles into Ansible repos? We’ve just started trying this out because we are incorporating roles from affiliated public role repos as submodules, and we need to manage integration of public roles into private “master” repos. We need to be able to make edits to submodules and push those out to the public roles without a lot of overhead. We also need to keep multiple developers in sync. Any experiences, regrets, or recommendations with regards to Ansible roles as submodules? Any recommendations for submodule workflows, or alternate strategies such as managed vendoring ala golang? ---
**Author:** ![willthames](https://avatars.discourse-cdn.com/v4/letter/w/8dc957/32.png) [@willthames](https://forum.ansible.com/u/willthames)\ **Post date:** [August 15, 2014, 5:35am UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954/2 "2014-08-15T05:35:55Z")
I think the solutions discussed in [https://groups.google.com/forum/#!topic/ansible-project/TawjChwaV08](https://groups.google.com/forum/#!topic/ansible-project/TawjChwaV08) start to look like managed vendoring ala golang. Not to say it’s the only solution and git submodules might work, but the above approach is where I’m thinking of going with managing versioning of roles. Will ---
**Author:** ![Jim\_Gumbley](https://avatars.discourse-cdn.com/v4/letter/j/958977/32.png) [@Jim\_Gumbley](https://forum.ansible.com/u/Jim_Gumbley)\ **Post date:** [August 15, 2014, 11:10am UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954/3 "2014-08-15T11:10:16Z")
Keep it simple solution is to just copy paste the code in. I’d wager for most vendored roles the benefits of the upstream changes will be outweighed by the cost of maintaining the submodule connections. ---
**Author:** ![Steffen\_Prince](https://avatars.discourse-cdn.com/v4/letter/s/3da27b/32.png) [@Steffen\_Prince](https://forum.ansible.com/u/Steffen_Prince)\ **Post date:** [August 15, 2014, 4:17pm UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954/4 "2014-08-15T16:17:03Z")
We are the maintainers of the upstream repos in this case. I’m starting to think, though, that we need to shift the burden to the side of keeping upstream repos up-to-date, and keep our working repositories nice and simple. I don’t want our working repos to be brittle, and I can already see that’s going to be the case with submodules. So what I intend to do is just vendor the roles in from the upstream repos so that developers can use a normal git workflow in the working repos. But I would like to look at scripting the process of updating our upstreams. We’ll have to live with either losing or recreating commit messages when updating our upstream repos, but I think it’s a small price to pay for a simplified and robust workflow in the working repos. ---
**Author:** ![Michael\_DeHaan1](https://avatars.discourse-cdn.com/v4/letter/m/5e9695/32.png) [@Michael\_DeHaan1](https://forum.ansible.com/u/Michael_DeHaan1)\ **Post date:** [August 15, 2014, 4:52pm UTC](https://forum.ansible.com/t/ansible-workflow-with-roles-as-git-submodules/15954/5 "2014-08-15T16:52:05Z")
Generally you’ll find roles in things like galaxy are just starting points, and it’s not expected that you follow them as upstream copies change. I would consider starting your own company roles repo, maybe call it foocorp-roles, as you are likely going to want modifications. But I would not look at it as per-project vendoring or anything complicated like that. It’s not source code, and most likely the content is not going to need to change, so use things as a starting point, and then make them your own. –Michael