Prep CI for publication

[nathanweatherly]

Build Collection tarball, prep to publish, and publish.

How many of ^ those steps can we integrate into CI for easy re-publish?

Notes: https://docs.ansible.com/ansible/latest/dev_guide/developing_collections_distributing.html#initial-configuration-of-your-distribution-server-or-servers

[nathanweatherly]

NOTE: Practice publishing on a local AAP before the big push.

[nathanweatherly]

Where to find Galaxy API Key: https://galaxy.ansible.com/me/preferences?extIdCarryOver=true&sc_cid=701f2000001OH6uAAG

[nathanweatherly]

So the actual build and publish steps aren't too hard with gitactions: https://github.com/nathanweatherly/totally-not-fake-ansible-collection/blob/main/.github/workflows/galaxy-publish.yml

I think we'll want to have multiple actions and a way to trigger those actions in multiple contexts.

For example, we run sanity and unit and publish checks on each PR, but before a publish (as the "publish pipeline"), I figure we'll want to run:

• version bump (prestep?)
• sanity tests
• unit tests
• integration tests (once we have some)
• doc update REQUIRED WITH VERSION BUMP
  • changelog generation?
• publication check
• actual publish

As i mentioned, those steps aren't all unique to the publishing pipeline, so I need to read up on a way for workflows to share steps.

[nathanweatherly]

Question: How to retract stinker publications?

[nathanweatherly]

Slack conversation about retraction:

https://ansible.slack.com/archives/CE3UL7F8V/p1647448764431789

Long and short, it's very uncommon to delete something from Galaxy

[nathanweatherly]

essentially what everyone has said, galaxy is very much the wild west but also hard to delete from (mainly just because the code downstream hasn't made it upstream). if its on there, view it as permanent unless it is a security risk

as for automation hub, we can delete individual versions or the entire collection