generated from ansible-collections/collection_template
-
Notifications
You must be signed in to change notification settings - Fork 3
185 lines (173 loc) · 7.86 KB
/
ansible-test.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
---
# README FIRST
# 1. Subscribe to https://github.com/ansible-collections/news-for-maintainers
# (click the Watch button on the homepage > Custom > Issues)
# and keep this matrix up to date in accordance to related announcements.
# Timely add new ansible-core versions and consider dropping support
# and testing against its EOL versions.
# 2. If your collection repository is under the ansible-collections org,
# please keep in mind that the number of GHA jobs is limited
# and shared across all the collections in the org.
# So, focusing on good test coverage of your collection,
# please avoid testing against unnecessary entities such as
# ansible-core EOL versions your collection does not support
# or ansible-core versions that are not EOL yet but not supported by the collection.
# 3. If you don't have unit or integration tests, remove corresponding sections.
# 4. If your collection depends on other collections ensure they are installed,
# add them to the "test-deps" input.
# 5. For the comprehensive list of the inputs supported by the
# ansible-community/ansible-test-gh-action GitHub Action, see
# https://github.com/marketplace/actions/ansible-test.
# 6. If you want to prevent merging PRs that do not pass all tests,
# make sure to add the "check" job to your repository branch
# protection once this workflow is added.
# It is also possible to tweak which jobs are allowed to fail. See
# https://github.com/marketplace/actions/alls-green#gotchas for more detail.
# 7. If you need help please ask in #community:ansible.com on Matrix
# or in bridged #ansible-community on the Libera.Chat IRC channel.
# See https://docs.ansible.com/ansible/devel/community/communication.html
# for details.
# 8. If your collection is [going to get] included in the Ansible package,
# it has to adhere to Python compatibility and CI testing requirements described in
# https://docs.ansible.com/ansible/latest/community/collection_contributors/collection_requirements.html.
name: CI
on:
# Run CI against all pushes (direct commits, also merged PRs), Pull Requests
push:
branches:
- main
- stable-*
pull_request:
# Run CI once per day (at 06:00 UTC)
# This ensures that even if there haven't been commits that we are still
# testing against latest version of ansible-test for each ansible-core
# version
schedule:
- cron: '0 6 * * *'
concurrency:
group: >-
${{ github.workflow }}-${{
github.event.pull_request.number || github.sha
}}
cancel-in-progress: true
jobs:
###
# Sanity tests (REQUIRED)
#
# https://docs.ansible.com/ansible/latest/dev_guide/testing_sanity.html
sanity:
name: Sanity (Ⓐ${{ matrix.ansible }}) - ${{ matrix.python }}
strategy:
matrix:
ansible:
# It's important that Sanity is tested against all stable-X.Y branches
# Testing against `devel` may fail as new tests are added.
# An alternative to `devel` is the `milestone` branch with
# gets synchronized with `devel` every few weeks and therefore
# tends to be a more stable target. Be aware that it is not updated
# around creation of a new stable branch, this might cause a problem
# that two different versions of ansible-test use the same sanity test
# ignore.txt file.
# Add new versions announced in
# https://github.com/ansible-collections/news-for-maintainers in a timely manner,
# consider dropping testing against EOL versions and versions you don't support.
- stable-2.15
- stable-2.16
- stable-2.17
- devel
# - milestone
python:
- '3.8'
- '3.9'
- '3.10'
- '3.11'
# Ansible-test on various stable branches does not yet work well with cgroups v2.
# Since ubuntu-latest now uses Ubuntu 22.04, we need to fall back to the ubuntu-20.04
# image for these stable branches. The list of branches where this is necessary will
# shrink over time, check out https://github.com/ansible-collections/news-for-maintainers/issues/28
# for the latest list.
runs-on: >-
${{ contains(fromJson(
'["stable-2.9", "stable-2.10", "stable-2.11"]'
), matrix.ansible) && 'ubuntu-20.04' || 'ubuntu-latest' }}
steps:
# Run sanity tests inside a Docker container.
# The docker container has all the pinned dependencies that are
# required and all Python versions Ansible supports.
- name: Perform sanity testing
# See the documentation for the following GitHub action on
# https://github.com/ansible-community/ansible-test-gh-action/blob/main/README.md
uses: ansible-community/ansible-test-gh-action@release/v1
with:
ansible-core-version: ${{ matrix.ansible }}
testing-type: sanity
target-python-version: ${{ matrix.python }}
# OPTIONAL If your sanity tests require code
# from other collections, install them like this
# test-deps: >-
# ansible.netcommon
# ansible.utils
# OPTIONAL If set to true, will test only against changed files,
# which should improve CI performance. See limitations on
# https://github.com/ansible-community/ansible-test-gh-action#pull-request-change-detection
pull-request-change-detection: false
###
# Unit tests (OPTIONAL)
#
# https://docs.ansible.com/ansible/latest/dev_guide/testing_units.html
units:
# Ansible-test on various stable branches does not yet work well with cgroups v2.
# Since ubuntu-latest now uses Ubuntu 22.04, we need to fall back to the ubuntu-20.04
# image for these stable branches. The list of branches where this is necessary will
# shrink over time, check out https://github.com/ansible-collections/news-for-maintainers/issues/28
# for the latest list.
runs-on: >-
${{ contains(fromJson(
'["stable-2.9", "stable-2.10", "stable-2.11"]'
), matrix.ansible) && 'ubuntu-20.04' || 'ubuntu-latest' }}
name: Units (Ⓐ${{ matrix.ansible }})
strategy:
# As soon as the first unit test fails, cancel the others to free up the CI queue
fail-fast: true
matrix:
ansible:
# Add new versions announced in
# https://github.com/ansible-collections/news-for-maintainers in a timely manner,
# consider dropping testing against EOL versions and versions you don't support.
- stable-2.15
- stable-2.16
- stable-2.17
- devel
# - milestone
steps:
- name: >-
Perform unit testing against
Ansible version ${{ matrix.ansible }}
# See the documentation for the following GitHub action on
# https://github.com/ansible-community/ansible-test-gh-action/blob/main/README.md
uses: ansible-community/ansible-test-gh-action@release/v1
with:
ansible-core-version: ${{ matrix.ansible }}
testing-type: units
# OPTIONAL If your unit tests require code
# from other collections, install them like this
test-deps: >-
ansible.netcommon
ansible.utils
# OPTIONAL If set to true, will test only against changed files,
# which should improve CI performance. See limitations on
# https://github.com/ansible-community/ansible-test-gh-action#pull-request-change-detection
pull-request-change-detection: false
check: # This job does nothing and is only used for the branch protection
# or multi-stage CI jobs, like making sure that all tests pass before
# a publishing job is started.
if: always()
needs:
- sanity
- units
runs-on: ubuntu-latest
steps:
- name: Decide whether the needed jobs succeeded or failed
uses: re-actors/alls-green@release/v1
with:
jobs: ${{ toJSON(needs) }}