Name: ansible-collection-netbox_community-ansible_modules
Version: 0.1.6
Release: 1%{?dist}
Summary: Miscellaneous modules for Ansible Playbooks
# note: The netbox collection has inconsistent licensing! There's an MIT
# license file but the headers to all of the source code say GPLv3+. So it's
# probably all GPLv3+ (unless the author has permission to get all of the code
# relicensed)
License: MIT and GPLv3+
URL: https://galaxy.ansible.com/netbox_community/ansible_modules
### Checkout from source because the collection hosted on galaxy isn't truly
### a source container. There could be build scripts that generate the
### collection from the repository chckout. ### There could be compiled ansible
### modules in there....
# Generated via:
# git clone https://github.com/netbox-community/ansible_modules
# pushd ansible_modules
### This depends on upstream having tagged their releases appropriately. With other
### upstreams you may find that you have to checkout a commit hash or package everything
### as snapshots.
# git checkout v0.1.6
# popd
# mv ansible_modules ansible-collection-netbox_community-ansible_modules-0.1.6
# tar -czvf ansible-collection-netbox_community-ansible_modules-0.1.6.tar.gz ansible-collection-netbox_community-ansible_modules-0.1.6
Source0: ansible-collection-netbox_community-ansible_modules-0.1.6.tar.gz
### By and large, collections will be noarch. But ansible modules can be
### compiled and even with other types of ansible plugins, they can contain
### python extension modules(which are compiled) so these won't always be noarch
BuildArch: noarch
### For /usr/bin/ansible-galaxy
BuildRequires: ansible
### Directory ownership and these plugins will be useless without ansible to run them
Requires: ansible
%description
This Ansible collection is a set of plugins for configuring netbox devices.
%prep
%autosetup
%build
### If this is an archful package (or even if it is noarch, it could still be more
### complicated than a simple checkout of the source repo), there may be a build
### step. Every collection could be different. One might use a Makefile for this,
### another might use cmake, etc. The only commonality is that you'd want to run
### the build step here, before running ansible-galaxy collection build
### make CFLAGS=%%{optflags}
### Builds the contents of the current working directory into a collection tarball.
### At first, I anticipate that most collections will actually mirror what's in their
### git repo but over time you'll start to encounter collections which have a build
### step of some sort that generates some files prior to creating the collection. You
### may end up having to run this command in a different directory or the upstream's
### build scripts may run this command for you
ansible-galaxy collection build
%install
rm -rf %{buildroot}
### In ansible-2.10::
### Use python_sitearch if the collection is arch-specific
### This feature is still being coded for 2.10 so the exact directory
### structure/names may still change.
### ansible-galaxy collection install \
### -p %%{buildroot}%%{python_sitelib}/ \
### ./netbox_community-ansible_modules-0.1.6.tar.gz
### In ansible-2.9, the ansible package comes configured with this in the
### collection path. Unfortunately it's a noarch location so any archful
### collections can't go here.
### The ansible package could add the 2.10 locations to the configuration file
### to use the 2.10 locations but when a user upgrades, they may not see and
### merge the changes to the configuration file so you have to consider whether
### that is acceptable
ansible-galaxy collection install -vvvvv \
-p %{buildroot}%{_datadir}/ansible/collections \
./netbox_community-ansible_modules-0.1.6.tar.gz
%check
### There should be a way to run the collection's test suite using ansible-test
### but I'm not familiar enough with this scenario to know if creating this
### directory hierarchy is the best way to accomplish this.
mkdir -p ansible_collections/netbox_community/ansible_modules
cp -pr tests plugins ansible_collections/netbox_community/ansible_modules
pushd ansible_collections/netbox_community/ansible_modules
ansible-test units --python %{python3_version}
popd
# integration tests aren't working under ansible-test yet. I see from
# upstream's .travis.yml that they just run them with ansible-playbook so
# this might be a case where it differs from standard practice
# (Would also need more BuildRequires to run the integration tests. Some
# integration tests might not be usable if they assume they can talk to the
# network)
#ansible-test integration
%files
# NOTE! This LICENSE file says MIT but the headers on the source code say
# GPLv3+. This needs to be corrected by upstream. Perhaps we should include
# a copy of the GPLv3 until that is resolved
%defattr (0644, root, root, 0755)
%license LICENSE
%doc README.md CONTRIBUTING.md CHANGELOG.md
### Ansible-2.10+
### The ansible package should own these two directories:
### %%{python_sitelib}/ansible_collections/
### %%{python_sitearch}/ansible_collections/
### The complete directory structure looks something like this:
### %%{python_sitelib}
### \ ansible_collections
### \ netbox
### \ ansible_modules
### + README.md [Could be removed in install and placed in docdir instead]
### + COPYING [Could be removed in install and placed in docdir instead]
### + Other files from the git repo [Also could be removed and placed
### elsewhere if they're needed. The plugins directory is the only thing
### that ansible will use at runtime]
### \ plugins
### \ modules [ There's other plugin types will have other subdirectories.
### module_utils, callback, cache, connection, etc]
### \ irc.py [ The actual module files]
### %%{python_sitelib}/ansible_collections/netbox/
### Ansible-2.9
%{_datadir}/ansible/collections/ansible_collections/
%changelog
* Sat Feb 15 2020 Toshio Kuratomi <toshio@fedoraproject.org> - 0.1.6-1
- Initial cut. There are possible bikesheds in here. For instance, I don't
know if ansible-collection-$NAMESPACE-$COLLECTION is the best naming standard