dbrennand
August 11, 2026, 8:59am
1
(This was split off from Pinning GHA actions/shared workflows to commits - #2 by felixfontein )
Regarding:
test-galaxy-import is only used by one repository: GitHub - ansible-collections/community.vmware: Ansible Collection for VMware · GitHub 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 ?
1 Like
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.
I created an issue (Shared workflow for Galaxy import might get deprecated/archived · Issue #2561 · ansible-collections/community.vmware · GitHub ) 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.
mariolenz
August 15, 2026, 12:36pm
4
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.
When you use antsibull-nox, you can simply add
[sessions.build_import_check]
run_galaxy_importer = true
to your antsibull-nox.toml file. (Documenation of this session .)
If you don’t use it yet, and want to use it for that, you can create a new antsibull-nox.toml file
version = 1
[sessions]
[sessions.build_import_check]
run_galaxy_importer = true
and a noxfile.py (as in Getting started - antsibull-nox – Antsibull Nox Helper , 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 to your collection.
2 Likes
mariolenz
August 17, 2026, 4:58pm
6
@dbrennand I’ve started to work on replacing this workflow in community.vmware . 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.
1 Like
mariolenz
August 19, 2026, 5:54pm
7
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.
1 Like
Hmm, I did another search, and I found quite a few collections using these actions:
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.
1 Like
mariolenz
August 20, 2026, 2:37pm
9
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.
1 Like
dbrennand
August 25, 2026, 7:40am
10
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:
NOT is:fork
There are 12 for ansible-community/github-action-build-collection and 7 for ansible-community/github-action-test-galaxy-import.
1 Like
dbrennand
August 25, 2026, 8:05am
11
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.
mariolenz
August 25, 2026, 2:25pm
12
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.
1 Like
dbrennand
August 26, 2026, 8:22am
13
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.
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
dbrennand
August 26, 2026, 12:52pm
14
I created an issue in all of the affected GitHub repositories.
github-action-build-collection — issue #17
opened 07:48AM - 26 Aug 26 UTC
> **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
<namespace>-<name>-<version>.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.
github-action-test-galaxy-import — issue #19
opened 08:16AM - 26 Aug 26 UTC
> **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.
@dbrennand thanks a lot for creating the PRs and issues!
