# Deprecate build collection and test import to Galaxy GitHub Actions and shared workflows **URL:** \ **Category:** Project Discussions\ **Tags:** ansible-galaxy, github, ci\ **Created:** [August 11, 2026, 8:59am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184 "2026-08-11T08:59:28Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 11, 2026, 8:59am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/1 "2026-08-11T08:59:28Z")
(This was split off from [Pinning GHA actions/shared workflows to commits - #2 by felixfontein](https://forum.ansible.com/t/46118/2)) Regarding: - [GitHub - ansible-community/github-action-test-galaxy-import: GitHub Action for testing Galaxy import of an Ansible collection · GitHub](https://github.com/ansible-community/github-action-test-galaxy-import) - [GitHub - ansible-community/github-action-build-collection: GitHub Action for building Ansible collections · GitHub](https://github.com/ansible-community/github-action-build-collection) `test-galaxy-import` is only used by one repository: [GitHub - ansible-collections/community.vmware: Ansible Collection for VMware · GitHub](https://github.com/ansible-collections/community.vmware) and `action-build-collection` is only used internally by `test-galaxy-import` from what I can see. Please correct me if I’m wrong. Is the time and effort being spent on maintaining these actions worth it? Furthermore, building a collection is quite simple, and both `antsibull-nox` and `tox-ansible` have ways of running Galaxy importer which I feel we could be encouraging for the other benefits for collection testing too. What are your thoughts @felixfontein? ---
**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:** [August 11, 2026, 9:19am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/2 "2026-08-11T09:19:59Z")
I’m fine with archiving both actions. They were useful when the alternative was to use Zuul (which took up to 20 minutes for what the actions were doing in a minute or so), but now that most collections moved on from them I don’t think they are needed anymore. ---
**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:** [August 14, 2026, 7:23pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/3 "2026-08-14T19:23:28Z")
I created an issue ([Shared workflow for Galaxy import might get deprecated/archived · Issue #2561 · ansible-collections/community.vmware · GitHub](https://github.com/ansible-collections/community.vmware/issues/2561)) in the community.vmware repository. Once they stop using the github-action-test-galaxy-import and github-action-build-collection actions/shared workflows, I’d archive these. ---
**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:** [August 15, 2026, 12:36pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/4 "2026-08-15T12:36:56Z")
Does anyone have any examples how other collections replaced this workflow? Might be really helpful for me. But don’t search! If you can’t name some examples just like this I’ll have to investigate myself. ---
**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:** [August 15, 2026, 12:55pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/5 "2026-08-15T12:55:26Z")
When you use antsibull-nox, you can simply add ```toml [sessions.build_import_check] run_galaxy_importer = true ``` to your antsibull-nox.toml file. ([Documenation of this session](https://docs.ansible.com/projects/antsibull-nox/config-file/#collection-build-and-galaxy-import-test).) If you don’t use it yet, and want to use it for that, you can create a new antsibull-nox.toml file ```toml version = 1 [sessions] [sessions.build_import_check] run_galaxy_importer = true ``` and a `noxfile.py` (as in [Getting started - antsibull-nox – Antsibull Nox Helper](https://docs.ansible.com/projects/antsibull-nox/getting-started/), or you can ask antsibull-nox to create it for you) and add a workflow like the one in [Running nox in CI - antsibull-nox – Antsibull Nox Helper](https://docs.ansible.com/projects/antsibull-nox/nox-in-ci/#run-extra-sanity-tests-with-change-detection) to your collection. ---
**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:** [August 17, 2026, 4:58pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/6 "2026-08-17T16:58:50Z")
@dbrennand I’ve started to work on [replacing this workflow in community.vmware](https://github.com/ansible-collections/community.vmware/pull/2563). There are some things I don’t fully understand, and I’ll have to figure out why the CI isn’t happy. But as I’ve said: I’m working on getting rid of this. ---
**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:** [August 19, 2026, 5:54pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/7 "2026-08-19T17:54:39Z")
I’ve removed `ansible-community/github-action-test-galaxy-import` from `community.vmware`. I’m not 100% happy with the way I’ve replaced it. But that’s _my_ problem, not yours. ---
**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:** [August 19, 2026, 6:32pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/8 "2026-08-19T18:32:48Z")
> [@dbrennand](#): > > - [GitHub - ansible-community/github-action-build-collection: GitHub Action for building Ansible collections · GitHub](https://github.com/ansible-community/github-action-build-collection) > > `test-galaxy-import` is only used by one repository: [GitHub - ansible-collections/community.vmware: Ansible Collection for VMware · GitHub](https://github.com/ansible-collections/community.vmware) and `action-build-collection` is only used internally by `test-galaxy-import` from what I can see. Please correct me if I’m wrong. Hmm, I did another search, and I found quite a few collections using these actions: - [Code search results · GitHub](https://github.com/search?q=ansible-community%2Fgithub-action-build-collection+path%3A%2F%5E%5C.github%5C%2Fworkflows%5C%2F%2F&type=code) - [Code search results · GitHub](https://github.com/search?q=ansible-community%2Fgithub-action-test-galaxy-import+path%3A%2F%5E%5C.github%5C%2Fworkflows%5C%2F%2F&type=code) I guess it’s a good idea to get them all to stop using these actions/shared workflows, but that will take more time than I initially thought. Especially the collection build action seems to be part of several collection release workflows. ---
**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:** [August 20, 2026, 2:37pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/9 "2026-08-20T14:37:19Z")
At least some of the search results seem to be forks of the “real” collections / main repos. So I guess it’s not as bad as it looks like at the first glance. But it will probably take some time to find out what repos should be ignored because they’re just forks and what repos are the important ones. That is, if there’s no way to filter the forks in the search query. I don’t know if (or how) this is possible. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 25, 2026, 7:40am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/10 "2026-08-25T07:40:47Z")
Hey @felixfontein Thanks for catching this, wow yeah there is quite a few more… @mariolenz I added the following to @felixfontein’s search query which excludes forks: ```auto NOT is:fork ``` > **[Build software better, together](https://github.com/search?q=ansible-community%2Fgithub-action-build-collection+path%3A%2F%5E%5C.github%5C%2Fworkflows%5C%2F%2F+NOT+is%3Afork&type=code)** > > GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects. > **[Build software better, together](https://github.com/search?q=ansible-community%2Fgithub-action-test-galaxy-import+path%3A%2F%5E%5C.github%5C%2Fworkflows%5C%2F%2F+NOT+is%3Afork&type=code)** > > GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects. There are 12 for ansible-community/github-action-build-collection and 7 for ansible-community/github-action-test-galaxy-import. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 25, 2026, 8:05am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/11 "2026-08-25T08:05:06Z")
How do you think we should approach this? @felixfontein @mariolenz My thinking is that we could give a ~6 month deprecation window. This gives folks a decent chunk of time to move? Wdyt? If it sounds good, we could create pinned issues in both `ansible-community/github-action-build-collection` and `ansible-community/github-action-test-galaxy-import` repositories mentioning that the action will be deprecated in 6 months with details on the exact month it will be deprecated, the reasoning behind it etc. Then, the issue body could include instructions on how to migrate for each action. ---
**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:** [August 25, 2026, 2:25pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/12 "2026-08-25T14:25:40Z")
I would also create issues in the repos using those workflows. It would be a bit of work, but since we can always use the same text it’ll be just some C&P. Oh, and mention it on Bullhorn. About the ~6 months deprecation window, that sounds OK and reasonable to me. ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 26, 2026, 8:22am UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/13 "2026-08-26T08:22:55Z")
Hey folks, I’ve begun work on this. I’ve created issues in each repository and pinned them with details on migration paths and other details for the deprecation. - [Deprecation notice: `github-action-build-collection` will be archived in February 2027 · Issue #17 · ansible-community/github-action-build-collection · GitHub](https://github.com/ansible-community/github-action-build-collection/issues/17) - [docs: link deprecation issue in README by dbrennand · Pull Request #18 · ansible-community/github-action-build-collection · GitHub](https://github.com/ansible-community/github-action-build-collection/pull/18) - [Deprecation notice: `github-action-test-galaxy-import` will be archived in February 2027 · Issue #19 · ansible-community/github-action-test-galaxy-import · GitHub](https://github.com/ansible-community/github-action-test-galaxy-import/issues/19) - [docs: link deprecation issue in README by dbrennand · Pull Request #20 · ansible-community/github-action-test-galaxy-import · GitHub](https://github.com/ansible-community/github-action-test-galaxy-import/pull/20) I submitted PRs to update the WARNING notices in each README to link to the issues with the migration guidance. I will begin creating issues in each of the impacted repositories later this week and announce in the Bullhorn too. Thanks both for your help on this 🙂 ---
**Author:** ![dbrennand](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dbrennand/32/7830_2.png) [@dbrennand](https://forum.ansible.com/u/dbrennand)\ **Post date:** [August 26, 2026, 12:52pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/14 "2026-08-26T12:52:16Z")
I created an issue in all of the affected GitHub repositories. ### `github-action-build-collection` **— issue #17** > > > \> \*\*Deprecation notice\*\* > \> > \> This action is deprecated and is planned to be arch…ived in \*\*February 2027\*\*. Please migrate existing workflows before then. > > \### Why is this action being deprecated? > > This action was useful when the main alternative for collection build and Galaxy import checks was a considerably slower Zuul workflow. The ecosystem has since moved on, and building an Ansible collection is now a small, well-supported CI/CD step that can be expressed directly in GitHub Actions. > > Maintaining a dedicated action and bundled reusable workflow for this narrow operation is no longer worth the maintenance cost. Collection maintainers can also use broader collection testing tools such as \[\`antsibull-nox\`\](https://docs.ansible.com/projects/antsibull-nox/) or \[\`tox-ansible\`\](https://github.com/ansible/tox-ansible) when they need a complete test workflow rather than only a build step. > > This decision and the migration discussion are documented in the \[Ansible forum thread\](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184). > > \### Timeline > > \- \*\*Now:\*\* The action is deprecated. New users should not adopt it. > \- \*\*Before February 2027:\*\* Existing users should migrate their workflows. > \- \*\*February 2027:\*\* This repository and its bundled reusable workflow are planned to be archived. > > \## Migration guidance > > The action performs three relevant operations: > > 1. Sets up Python and installs ansible-core. > 2. Optionally creates a Galaxy \`requirements.yml\` from dependencies in \`galaxy.yml\`. > 3. Runs \`ansible-galaxy collection build\`. > > These operations can be represented directly in a workflow. > > \### Basic collection build > > For a collection at the repository root: > > \`\`\`yaml > name: Build collection > > on: > push: > pull\_request: > > jobs: > build-collection: > runs-on: ubuntu-latest > permissions: > contents: read > > steps: > - name: Check out code > uses: actions/checkout@v7 > > - name: Set up Python > uses: actions/setup-python@v7 > with: > python-version: '3.13' > > - name: Install ansible-core > run: python -m pip install ansible-core > > - name: Build collection > run: ansible-galaxy collection build --output-path dist > > - name: Upload collection artifact > uses: actions/upload-artifact@v7 > with: > name: collection-build-${{ github.sha }} > path: dist/ > \`\`\` > > Pin GitHub Actions to commit SHAs if that is the repository's CI policy. The Python and ansible-core versions should also be selected and pinned according to the collection's supported test matrix. The deprecated action currently defaults to Python \`3.13\` and the \`stable-2.18\` ansible-core branch; repositories that need equivalent behavior should choose a corresponding explicit ansible-core version or branch. > > The build command creates an artifact named from the collection metadata: > > \`\`\`text > \-\-\.tar.gz > \`\`\` > > \### Collections in a subdirectory > > Set the working directory to the directory containing \`galaxy.yml\` and keep the output directory outside that source tree: > > \`\`\`yaml > - name: Build collection > working-directory: collections/ansible\_collections/example/demo > run: ansible-galaxy collection build --output-path "$GITHUB\_WORKSPACE/dist" > \`\`\` > > The deprecated action's \`subdirectory\` input serves the same purpose. > > \### Creating \`requirements.yml\` > > The \`collection-requirements-path\` input in \`action.yml\` is optional. When supplied, the action reads the \`dependencies\` mapping from \`galaxy.yml\` and writes a Galaxy requirements file with one entry per dependency: > > \`\`\`yaml > collections: > - name: community.general > source: https://galaxy.ansible.com > version: '\>=8.0.0' > \`\`\` > > The action writes \`collections: \[\]\` when there are no dependencies. It sorts dependency names and preserves each dependency's version constraint. The following step reproduces that behavior and writes the file into the build artifact directory: > > \`\`\`yaml > - name: Create Galaxy requirements file > env: > COLLECTION\_DIR: . > shell: python > run: | > import os > from pathlib import Path > import yaml > > collection\_dir = Path(os.environ\['COLLECTION\_DIR'\]) > galaxy\_file = collection\_dir / 'galaxy.yml' > requirements\_file = Path('dist/requirements.yml') > > with galaxy\_file.open('rb') as stream: > galaxy = yaml.safe\_load(stream) or {} > > requirements = {'collections': \[\]} > for name, version in sorted((galaxy.get('dependencies') or {}).items()): > requirements\['collections'\].append({ > 'name': name, > 'source': 'https://galaxy.ansible.com', > 'version': version, > }) > > requirements\_file.parent.mkdir(parents=True, exist\_ok=True) > with requirements\_file.open('w', encoding='utf-8') as stream: > yaml.safe\_dump(requirements, stream, sort\_keys=False) > \`\`\` > > For a collection in a subdirectory, change \`COLLECTION\_DIR\` to that directory, for example: > > \`\`\`yaml > env: > COLLECTION\_DIR: collections/ansible\_collections/example/demo > \`\`\` > > Because ansible-core brings the required YAML library into the environment, this step can run after the ansible-core installation step above. If the repository manages its Python dependencies separately, ensure \`PyYAML\` is installed before running the \`requirements.yml\` generator described above. > > The generated file can then be uploaded with the collection artifact: > > \`\`\`yaml > - name: Upload collection and requirements > uses: actions/upload-artifact@v7 > with: > name: collection-build-${{ github.sha }} > path: dist/ > \`\`\` > > \### Add an explicit collection version > > The current action writes \`version: 0.0.1\` into \`galaxy.yml\` when no version is present. A direct \`ansible-galaxy collection build\` workflow should not rely on that implicit fallback. Add and maintain an explicit \`version\` in \`galaxy.yml\`, or generate the version as part of the repository's release process before the build step. > > \### Questions and migration reports > > Please comment on this issue with: > > \- A link to the migration pull request or commit. > \- Any problems encountered while replacing this action. > \- Any collection-specific requirements that are not covered by the examples above. > > Thank you to everyone who used and maintained this action. - [Scalified/ansible-services-collection #20](https://github.com/Scalified/ansible-services-collection/issues/20 "https://github.com/Scalified/ansible-services-collection/issues/20") - [Scalified/ansible-setup-collection #47](https://github.com/Scalified/ansible-setup-collection/issues/47 "https://github.com/Scalified/ansible-setup-collection/issues/47") - [ShravanDev050/Ansible-Project #1](https://github.com/ShravanDev050/Ansible-Project/issues/1 "https://github.com/ShravanDev050/Ansible-Project/issues/1") - [ansible-community/github-action-test-galaxy-import #21](https://github.com/ansible-community/github-action-test-galaxy-import/issues/21 "https://github.com/ansible-community/github-action-test-galaxy-import/issues/21") - [ceems-dev/ansible #174](https://github.com/ceems-dev/ansible/issues/174 "https://github.com/ceems-dev/ansible/issues/174") - [f9n/ansible-collection #12](https://github.com/f9n/ansible-collection/issues/12 "https://github.com/f9n/ansible-collection/issues/12") - [kravietz/ansible-collection-freebsd #1](https://github.com/kravietz/ansible-collection-freebsd/issues/1 "https://github.com/kravietz/ansible-collection-freebsd/issues/1") - [nautobot/nautobot-ansible #767](https://github.com/nautobot/nautobot-ansible/issues/767 "https://github.com/nautobot/nautobot-ansible/issues/767") - [prometheus-community/ansible #884](https://github.com/prometheus-community/ansible/issues/884 "https://github.com/prometheus-community/ansible/issues/884") - [sigp/triton #70](https://github.com/sigp/triton/issues/70 "https://github.com/sigp/triton/issues/70") ### `github-action-test-galaxy-import` **— issue #19** > > > \> \*\*Deprecation notice\*\* > \> > \> This GitHub Action and its bundled reusable workflo…w are deprecated and are planned to be archived in \*\*February 2027\*\*. Please migrate existing workflows before then. > > \### What is being deprecated? > > This repository provides: > > \- The \`github-action-test-galaxy-import\` composite action. > \- The bundled \`.github/workflows/test-galaxy-import.yml\` reusable workflow. > > The current composite action requires an \`artifact-path\` and optionally accepts \`collection-requirements-path\` and \`importer-config-path\`. Its current defaults are Python \`3.13\` and the \`stable-2.18\` ansible-core branch. > > \### Why is this being deprecated? > > These actions were useful when the main alternative for collection build and Galaxy import checks was a considerably slower Zuul workflow. Most collections have since moved to other testing approaches, and maintaining a dedicated action and shared workflow for this narrow operation is no longer worth the maintenance cost. > > The action also combines several operations that collection test tooling can manage as part of a broader, reproducible test environment: > > 1. Installs \`ansible-core\`. > 2. Installs \`galaxy-importer\`. > 3. Optionally installs collection dependencies from a requirements file with \`ansible-galaxy collection install --pre\`. > 4. Runs \`python -m galaxy\_importer.main\` against the collection artifact. > 5. Emits GitHub warnings for importer output lines beginning with \`ERROR:\`. > > The bundled reusable workflow additionally builds the collection artifact before running the importer. Collection maintainers can replace this narrow workflow with a complete, locally reproducible collection test setup using \[\`antsibull-nox\`\](https://docs.ansible.com/projects/antsibull-nox/) or \[\`tox-ansible\`\](https://ansible.readthedocs.io/projects/tox-ansible/). > > The decision and migration discussion are documented in the \[Ansible forum thread\](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184). > > \### Timeline > > \- \*\*Now:\*\* The action and bundled workflow are deprecated. New users should not adopt them. > \- \*\*Before February 2027:\*\* Existing users should migrate their workflows. > \- \*\*February 2027:\*\* This repository and its bundled reusable workflow are planned to be archived. > > \## Migration guidance > > Choose the migration that best fits the collection's existing test infrastructure. > > \### Option 1: use \`antsibull-nox\` > > \`antsibull-nox\` can run the collection build and Galaxy importer check as a named nox session. Add the following to \`antsibull-nox.toml\`: > > \`\`\`toml > version = 1 > > \[sessions\] > > \[sessions.build\_import\_check\] > run\_galaxy\_importer = true > \`\`\` > > Add a \`noxfile.py\` that loads this configuration. The following is the same pattern used by \`community.vmware\`: > > \`\`\`python > \# The following metadata allows Python runners and nox to install the required > \# dependencies for running this Python script: > \# > \# /// script > \# dependencies = \["nox\>=2025.02.09", "antsibull-nox"\] > \# /// > > import sys > > import nox > > try: > import antsibull\_nox > except ImportError: > print("You need to install antsibull-nox in the same Python environment as nox.") > sys.exit(1) > > > antsibull\_nox.load\_antsibull\_nox\_toml() > > > if \_\_name\_\_ == "\_\_main\_\_": > nox.main() > \`\`\` > > Then add a workflow to run nox: > > \`\`\`yaml > \--- > name: nox > 'on': > push: > branches: > - main > - stable-\* > pull\_request: > > permissions: > contents: read > > jobs: > nox: > runs-on: ubuntu-latest > name: Run nox > steps: > - name: Check out collection > uses: actions/checkout@v7 > with: > persist-credentials: false > > - name: Run nox > uses: ansible-community/antsibull-nox@efe6769cb9fa52e98fd6b3a4711dbd588e5512ce > \`\`\` > > Change the \`main\` and \`stable-\*\` branch filters in this example as needed for the collection's branch layout. > > Pin the GitHub Actions used by the workflow according to the collection's CI policy. The SHA above is the one currently used by \`community.vmware\`; update it to the approved version when adopting the workflow. > > The \`build\_import\_check\` session builds the collection and runs the Galaxy importer locally in the nox environment, so the check can be run both in CI and during local development: > > \`\`\`bash > uv run nox -s build\_import\_check > \`\`\` > > Depending on the collection's existing nox setup, maintainers may run the session with the repository's normal nox command instead. > > \#### \`community.vmware\` reference implementation > > \`community.vmware\` removed the old shared workflow in \[PR #2563\](https://github.com/ansible-collections/community.vmware/pull/2563), which merged on August 19, 2026. The resulting implementation provides a concrete migration example: > > \- \[\`antsibull-nox.toml\`\](https://github.com/ansible-collections/community.vmware/blob/main/antsibull-nox.toml) > \- \[\`noxfile.py\`\](https://github.com/ansible-collections/community.vmware/blob/main/noxfile.py) > \- \[\`.github/workflows/nox.yml\`\](https://github.com/ansible-collections/community.vmware/blob/main/.github/workflows/nox.yml) > \- \[Migration PR #2563\](https://github.com/ansible-collections/community.vmware/pull/2563) > > The original migration was tracked in \[\`community.vmware\` issue #2561\](https://github.com/ansible-collections/community.vmware/issues/2561). > > \### Option 2: use \`tox-ansible\` > > \[\`tox-ansible\`\](https://github.com/ansible/tox-ansible) integrates collection testing with tox-managed environments and supports a dedicated \`galaxy\` environment that builds the collection and runs \`galaxy-importer\`. > > Install \`tox-ansible\` and add its configuration to the collection's \`pyproject.toml\`: > > \`\`\`toml > \[tool.tox\] > requires = \["tox\>=4.2"\] > > \[tool.tox-ansible\] > \`\`\` > > List the generated environments and run the Galaxy environment: > > \`\`\`bash > uv run tox list --ansible > uv run tox -e galaxy --ansible > \`\`\` > > This approach is useful when the collection already uses tox-ansible for sanity, unit, integration, or Molecule testing, because the Galaxy importer check becomes another reproducible tox environment rather than a separate GitHub only workflow. > > \### Existing custom importer workflows > > Collections with specialised Galaxy importer configuration or custom artifact/dependency handling can keep those steps in a normal GitHub Actions job. The direct equivalent of this action is: > > \`\`\`yaml > \- name: Set up Python > uses: actions/setup-python@v7 > with: > python-version: '3.13' > > \- name: Install ansible-core and Galaxy importer > run: | > python -m pip install ansible-core galaxy-importer > > \- name: Install collection dependencies > if: ${{ hashFiles('requirements.yml') != '' }} > run: ansible-galaxy collection install --pre --requirements-file requirements.yml > > \- name: Run Galaxy importer > run: python -m galaxy\_importer.main dist/example-demo-1.0.0.tar.gz > \`\`\` > > If an importer configuration file is required, preserve the equivalent environment variable used by the action: > > \`\`\`yaml > \- name: Run Galaxy importer with custom configuration > env: > GALAXY\_IMPORTER\_CONFIG: importer-config.cfg > run: python -m galaxy\_importer.main dist/example-demo-1.0.0.tar.gz > \`\`\` > > \### Questions and migration reports > > Please comment on this issue with: > > \- A link to the migration pull request or commit. > \- Which replacement tooling was selected. > \- Any problems encountered while replacing this action. > \- Any collection-specific requirements that are not covered by the examples above. > > Thank you to everyone who used and maintained this action. - [cloudera-labs/cloudera.cloud #309](https://github.com/cloudera-labs/cloudera.cloud/issues/309 "https://github.com/cloudera-labs/cloudera.cloud/issues/309") - [cloudera-labs/cloudera.cluster #353](https://github.com/cloudera-labs/cloudera.cluster/issues/353 "https://github.com/cloudera-labs/cloudera.cluster/issues/353") - [cloudera-labs/cloudera.exe #337](https://github.com/cloudera-labs/cloudera.exe/issues/337 "https://github.com/cloudera-labs/cloudera.exe/issues/337") - [hifis-net/ansible-collection-toolkit #624](https://github.com/hifis-net/ansible-collection-toolkit/issues/624 "https://github.com/hifis-net/ansible-collection-toolkit/issues/624") - [os-migrate/os-migrate #798](https://github.com/os-migrate/os-migrate/issues/798 "https://github.com/os-migrate/os-migrate/issues/798") - [os-migrate/vmware-migration-kit #270](https://github.com/os-migrate/vmware-migration-kit/issues/270 "https://github.com/os-migrate/vmware-migration-kit/issues/270") ---
**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:** [August 27, 2026, 6:40pm UTC](https://forum.ansible.com/t/deprecate-build-collection-and-test-import-to-galaxy-github-actions-and-shared-workflows/46184/15 "2026-08-27T18:40:44Z")
@dbrennand thanks a lot for creating the PRs and issues!