# Opening issues against all collections in Ansible for core-2.19 template testing **URL:** \ **Category:** Collection Development\ **Tags:** templating, community-wg\ **Created:** [April 11, 2025, 1:44pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678 "2025-04-11T13:44:07Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 11, 2025, 1:44pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/1 "2025-04-11T13:44:07Z")
Based on chat last week, we are considering autogenerating an issue to every collection repo included in the Ansible package. The goal here is to ensure they are aware of the data tagging feature and will (hopefully) engage in testing ahead of time to ensure their collections/playbooks/roles are compatible. So the goal of this post is to draft out what would be in that autogenerated issue. I added the next meeting tag, but I think we need to resolve this before the meeting so we can engage all those collection owners as soon as possible. I’m thinking of something like the following (note I’m hoping the PR merges into devel soon so that’s how I wrote the issue text. Can change to fallable if needed) **issue title** : Validate compatibility with ansible-core 2.19 **Issue body:** ansible-core has implemented an extensive rewrite of templating and error handling as part of the [data tagging feature](https://github.com/ansible/ansible/pull/84621) coming in core-2.19. You can find information about this change in that PR description, as well as in the [core 2.19 porting guide](https://docs.ansible.com/ansible-core/devel/porting_guides/porting_guide_core_2.19.html). Please read [background and testing requests,](https://forum.ansible.com/t/data-tagging-preview-and-testing/40759) which details where you can file potential bugs. Collections that are part of the Ansible community package to MUST test against `ansible-core 2.19` to ensure they continue to work with the updated core. Collections which are not compatible with `ansible-core 2.19` will be removed from Ansible 12. You can choose to test against the `stable-2.19` branch, the `devel` branch, the `milestone` branch, or the pre-release/released versions of `ansible-core 2.19` available on [Pypi](https://pypi.org/project/ansible-core/#history). This should be an ongoing verification/check until the release of core 2.19 to ensure compatibility with any bugfixes or changes that happen until then. You can find advice from fellow maintainers at [Making a collection compatible with data tagging](https://forum.ansible.com/t/making-a-collection-compatible-with-data-tagging/41717), and we welcome your additions to that forum topic. **Note:** You are not required to implement data tagging as part of this request, though we do recommend you consider where it can improve the quality of your collection. This issue is focused on ensuring you have verified your collection works with `ansible-core 2.19` in order to remain included in the Ansible 12 community package. We ask that you resolve any problems and link those PRs to this issue. If you do not find any problems with your integration/unit testing, please provide that comment and a pointer to your test results before closing this issue as done. You can reach out on the [Ansible forum](https://forum.ansible.com/t/data-tagging-preview-and-testing/40759) for more help or discussion. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 11, 2025, 2:16pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/2 "2025-04-11T14:16:28Z")
> [@samccann](#): > > We need each collection owner to now test against ansible-core devel branch to ensure your collection continues to work with the updated core. You want to open the issue only in repositories that are part of the Ansible community package, right? So maybe make this clear: > We need the owners of collections that are part of the Ansible community package to now test against ansible-core devel branch to ensure they continue to work with the updated core. Otherwise, people who maintain a collection that is and another one that isn’t might wonder why they get this issue for the one but not the other. Rest LGTM at first glance. ---
**Author:** ![gundalow](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gundalow/32/99_2.png) [@gundalow](https://forum.ansible.com/u/gundalow)\ **Post date:** [April 12, 2025, 6:23pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/3 "2025-04-12T18:23:30Z")
I wonder if it would be worth being very explicit about the call to action and how to test, Also can we say that if you are already testing against `devel` check your CI runs after Monday 14th April still pass ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [April 12, 2025, 6:43pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/4 "2025-04-12T18:43:59Z")
Should we include some practical advice? For example: > If your unit tests start failing because you mock module arguments like this: > > ```python > from ansible.module_utils import basic > args = json.dumps({'ANSIBLE_MODULE_ARGS': args}) > basic._ANSIBLE_ARGS = to_bytes(args) > ... execute the module ... > > ``` > > This no longer works, you need to use the `ansible.module_utils.testing.patch_module_args()` context manager instead: > > ```python > from ansible.module_utils.testing import patch_module_args > with patch_module_args(args): > ... execute the module ... > > ``` > > One way to handle this for both older and newer ansible-core versions is to create your own context manager: > > ```python > @_contextlib.contextmanager > def set_module_args(args): > """ > Context manager that sets module arguments for AnsibleModule > """ > if '_ansible_remote_tmp' not in args: > args['_ansible_remote_tmp'] = '/tmp' > if '_ansible_keep_remote_files' not in args: > args['_ansible_keep_remote_files'] = False > > try: > from ansible.module_utils.testing import patch_module_args > except ImportError: > # Before data tagging support was merged, this was the way to go: > from ansible.module_utils import basic > serialized_args = to_bytes(json.dumps({'ANSIBLE_MODULE_ARGS': args})) > with patch.object(basic, '_ANSIBLE_ARGS', serialized_args): > yield > else: > # With data tagging support, we have a new helper for this: > with patch_module_args(args): > yield > > ``` > > Then you can always run: > > ```python > with set_module_args({...}): > ... execute the module ... > > ``` ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 13, 2025, 12:38pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/5 "2025-04-13T12:38:40Z")
Some practical advice might be helpful and sounds like a good idea to me. But I wonder if this wouldn’t make the issue text very long. And it would be also hard to add more practical advice in case it would be useful or needed. How about having the advice from @felixfontein somewhere else and just add a link to the issue? Maybe on the forum. We could re-use [Data tagging playground](https://forum.ansible.com/t/39909) for this or [Data Tagging preview and testing](https://forum.ansible.com/t/40759) or create a new thread like `Making a collection compatible with data tagging` or something. Then we would have a central place to add more advice when needed. And this would also mean that we can answer general questions in one place once instead of repeatedly in several issues. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [April 13, 2025, 1:15pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/6 "2025-04-13T13:15:42Z")
Yeah, it would be better to have a place here in the forum (or on GH) to collect such advice. I’m not sure what’s the best place for it… A new thread “Making a collection compatible with Data Tagging” sounds good to me! ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 13, 2025, 3:02pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/7 "2025-04-13T15:02:26Z")
> [@gundalow](#): > > Also can we say that if you are already testing against `devel` check your CI runs after Monday 14th April still pass Additionally, we might also suggest to start testing against `stable-2.19`. Out of curiosity, what about the `milestone` branch? Is it dead, or will it be updated when the data tagging PR is merged / ansible-core beta 1 is released? It looks quite old to me. Maybe [@Core](https://forum.ansible.com/groups/core) can enlighten us about this. ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 14, 2025, 3:18pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/8 "2025-04-14T15:18:48Z")
Good idea about a new forum post to cover the hints and tips. @felixfontein are you up for creating it since you had a good batch of ideas to start with? I can also go into the other two existing data tagging topic and add some cross linking between these three posts so folks can find it all. ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 14, 2025, 3:24pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/9 "2025-04-14T15:24:54Z")
@felixfontein - I’m going to creat the post now and you can add your stuff as the first comment. I want to craft a special bullhorn edition today that will be data tagging/core-2.19 focused so I need that link to be live in the next few minutes 🙂 ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 14, 2025, 3:31pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/10 "2025-04-14T15:31:53Z")
It’s here - [Making a collection compatible with data tagging](https://forum.ansible.com/t/making-a-collection-compatible-with-data-tagging/41717) ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [April 14, 2025, 3:42pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/11 "2025-04-14T15:42:02Z")
Thanks for creating the topic! I’ve copied my unit test advice over from above. I’m not sure whether I’ll have time for creating a newsbot announcement, as I’ll probably be busy with rebasing/merging PRs and potentially creating new ones / updating existing ones, and I’ll be gone for a few hours this evening as well to an external event… ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 14, 2025, 3:54pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/12 "2025-04-14T15:54:50Z")
no rush on the newsbot. I’ve manually added it to this week’s bullhorn. But would be good to have it there as a reminder for next week’s bullhorn readers… and thanks!! ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 14, 2025, 5:23pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/13 "2025-04-14T17:23:23Z")
> [@gundalow](#): > > Also can we say that if you are already testing against `devel` check your CI runs after Monday 14th April still pass I think that the advise is to _not_ test against `devel` and use `milestone` instead. The reason is that `devel` might be broken temporarily, but `milestone` shouldn’t. The good news is that it looks like the DT stuff has been added to the [milestone](https://github.com/ansible/ansible/tree/milestone) branch. ---
**Author:** ![mattclay](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mattclay/32/268_2.png) [@mattclay](https://forum.ansible.com/u/mattclay)\ **Post date:** [April 14, 2025, 6:14pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/14 "2025-04-14T18:14:19Z")
Testing against `devel` is fine, as long as you’re prepared to handle the possibility that it’s broken. If you’re not, then testing against `milestone` is advised instead. If you’re up for it, testing against both will help catch issues earlier – but doing so comes with the cost of more effort on the part of collection maintainers. ---
**Author:** ![felixfontein](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/felixfontein/32/7530_2.png) [@felixfontein](https://forum.ansible.com/u/felixfontein)\ **Post date:** [April 14, 2025, 7:31pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/15 "2025-04-14T19:31:10Z")
I prefer testing against `devel` over testing against `milestone` since the CI breakages that a `milestone` bump carries are often larger than the more frequent CI breakages that `devel` gives me. I can’t just take 1-2 days off from work to fix all CIs once `milestone` gets bumped, but I can invest a couple of hours to fix all CIs when something happens in `devel`. For someone who works full-time on this, or is getting paid to do this, the trade-off might be different. ---
**Author:** ![gotmax23](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gotmax23/32/106_2.png) [@gotmax23](https://forum.ansible.com/u/gotmax23)\ **Post date:** [April 15, 2025, 3:04am UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/16 "2025-04-15T03:04:43Z")
Hi everyone, just getting caught up on forum posts. Thanks for starting the discussion, @samccann. Here are some suggestions about the proposed text: > the [draft porting guide](https://github.com/ansible/ansible-documentation/pull/2429). Ideally, we could have this merged before creating these issues now that the Core change has been merged so we don’t need to link to draft PRs in the announcement, > You can find advice from your peers at [Making a collection compatible with data tagging](https://forum.ansible.com/t/making-a-collection-compatible-with-data-tagging/41717). Maybe “fellow maintainers” instead of “peers”? “Peers” seems a bit formal to me. > This issue is focused on ensuring you have verified your collection works with ansible-core devel in order to remain included in Ansible 12 community package. This (and other text) implies that this is a requirement to remain included in the package, but I think we need to be more up-front and explicit (but obviously not overly harsh or rude), as it’s one of the most fundamental inclusion requirements that the collections included in an Ansible version are actually functional and compatible with its associated Core version. ---
**Author:** ![gotmax23](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/gotmax23/32/106_2.png) [@gotmax23](https://forum.ansible.com/u/gotmax23)\ **Post date:** [April 15, 2025, 3:08am UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/17 "2025-04-15T03:08:35Z")
Also, we should announce this in #news-for-maintainers. ---
**Author:** ![mariolenz](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/mariolenz/32/108_2.png) [@mariolenz](https://forum.ansible.com/u/mariolenz)\ **Post date:** [April 15, 2025, 3:21pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/18 "2025-04-15T15:21:03Z")
> [@gotmax23](#): > > > This issue is focused on ensuring you have verified your collection works with ansible-core devel in order to remain included in Ansible 12 community package. > > This (and other text) implies that this is a requirement to remain included in the package, but I think we need to be more up-front and explicit (but obviously not overly harsh or rude), as it’s one of the most fundamental inclusion requirements that the collections included in an Ansible version are actually functional and compatible with its associated Core version. I think I know what you mean, but I’m not able to come up with a good wording ATM. Anyway, reading this a second time the original text is a little bit misleading. The collections included in ACP have to be compatible with the associated Core version, and that’s 2.19. Testing against the devel branch isn’t really a requirement, just a way to find any issues early. But now that there are the ansible-core 2.19.0b1 PyPI package and the stable-2.19 branch in the core repo available, they are also good ways to test. Ultimately, the collections should work with ansible-core 2.19.0 and _not_ devel. ---
**Author:** ![samccann](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/samccann/32/18_2.png) [@samccann](https://forum.ansible.com/u/samccann)\ **Post date:** [April 22, 2025, 6:27pm UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/19 "2025-04-22T18:27:54Z")
Thanks everyone! I updated the text abit. Can you take another look? I’m planning on generating the issues in the next couple of days with the text at the start of this topic. ---
**Author:** ![Andersson007](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/andersson007/32/89_2.png) [@Andersson007](https://forum.ansible.com/u/Andersson007)\ **Post date:** [April 23, 2025, 9:22am UTC](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678/20 "2025-04-23T09:22:06Z")
> Collections that are part of the Ansible community package to MUST test against ansible-core 2.19 to ensure they continue to work with the updated core. Collections which are not compatible with ansible-core 2.19 will be removed from Ansible 12. You can choose to test against the stable-2.19 branch, the milestone branch, or the pre-release/released versions of ansible-core 2.19 available on Pypi. ~~Should we also mention a recommendation to test against `devel` by adding it to a testing matrix? It’s not specific to 2.19,. but imo good in general, and it’ll also catch changes from 2.19 for now i guess~~ UPDATE: Now I see that stable-2.19 was created a couple of days ago. [Next page](https://forum.ansible.com/t/opening-issues-against-all-collections-in-ansible-for-core-2-19-template-testing/41678.md?page=2)