Releases not being pulled by Ansible Galaxy

[mmolinac]

I've noticed that the last version published in Ansible Galaxy is 2.1.2.
However, according to the Contributing guidelines page, a new release on GitHub and adding a tag to the master branch is all that's required for it to work.
Looks like something else is missing, because new version 2.2.0 is tagged and it's not on Ansible Galaxy.

[mmolinac]

It could be related to tests not building on Travis CI.
I'm afraid I'm not familiar with the errors on some of the tests (CentOS).

[pkuczynski]

@lpaulmp @thbar @sfgeorge any idea?

[thbar]

I looked a bit into this, just sharing initial bits at this point.

The Travis setup has been removed in #235.

It used to include this:

rvm1-ansible/.travis.yml

Lines 54 to 55 in 0fcf5f3

	notifications:
	webhooks: https://galaxy.ansible.com/api/v1/notifications/

I have no idea if it worked or not, but it looks like an interesting suppression, which could be a cause.

Also I came across this interesting post which mentions that also.

https://www.jeffgeerling.com/blog/2020/automatically-building-and-publishing-ansible-galaxy-collections

I believe re-instating a post-release (or post something) POST over there will likely help.

I will see if I can make some time to re-instate that this week (but please anyone feel free to jump at it whenever you want if it's doable on your side).

[pkuczynski]

There are plenty of gha which allows to send web hook notifications. Thing is that Ansible Galaxy seems to only support Travis at the moment: ansible/galaxy#1379

Maybe we should just mimic travis payload, as someone suggested? @sfgeorge do you wanna have a look at this or shall we wait for @thbar?

[pkuczynski]

Looks like @sfgeorge already had a look into this ansible/galaxy#46 and gave up? Can you say something about it @sfgeorge ?

[pkuczynski]

Some suggestions here too ansible/galaxy#2070

[sfgeorge]

@pkuczynski I didn't start any actual legwork on it, but my comment on ansible/galaxy#46 suggests that perhaps someone write a reusable GitHub Action that uses GitHub Actions many available context variables and transforms them to make a POST to Ansible Galaxy mimic'ing a POST from Travis-CI.

Pro: Would avoid having to touch a line of code of Galaxy.
Cons: Some might consider this a kludge. (I think of it as just re-using an "API" that's already been established.)

[pkuczynski]

So it looks there are couple of GHA which allows to achieve the same result: https://github.com/marketplace?type=actions&query=galaxy+

@sfgeorge would you like to tackle that as you were the original author of CI change?

[sfgeorge]

@pkuczynski short answer – Yeah, I can definitely take a stab, will do 👍

Longer answer – Those solutions use ansible-galaxy role import ..., which to my understanding will publish the latest version of the role, but not update the build status. In truth, we should do both. I can take a stab at each.

[pkuczynski]

Awesome! Thanks!

[pkuczynski]

@sfgeorge any chance you can give it a shot soon?

[claasz]

For anyone wondering how to install 2.2.0 in the meantime: As a workaround you can use
$ ansible-galaxy install https://github.com/rvm/rvm1-ansible/archive/refs/tags/v2.2.0.tar.gz

[sfgeorge]

@pkuczynski Apologies, it may be a little while before I can get to this due to other commitments.

[coldnebo]

For anyone wondering how to install 2.2.0 in the meantime: As a workaround you can use $ ansible-galaxy install https://github.com/rvm/rvm1-ansible/archive/refs/tags/v2.2.0.tar.gz

Still an issue:

TASK [rvm.ruby : Import GPG keys from keyservers] ****************************************************************************************************
failed: [localhost] (item=hkp://pool.sks-keyservers.net) => {"ansible_loop_var": "item", "changed": false, "cmd": "gpg --batch --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB", "delta": "0:00:20.045397", "end": "2022-06-13 14:08:56.849421", "item": "hkp://pool.sks-keyservers.net", "

ok, this works:

$ cd /home/lkyrala/.ansible/roles
$ ansible-galaxy install https://github.com/rvm/rvm1-ansible/archive/refs/tags/v2.2.0.tar.gz
$ rm -rf rvm.ruby
$ mv v2.2.0 rvm.ruby

then run your playbook as usual:

$ ansible-playbook ...
...
TASK [rvm.ruby : Import GPG keys from keyservers] ****************************************************************************************************
ok: [localhost] => (item=hkp://keys.openpgp.org)
...

[mmolinac]

@sfgeorge Have you been able to give a look at the publishing issue?

[sfgeorge]

Unfortunately I haven't had time to do this. But I want to share my understanding of a few options we have for solving this problem if someone is able to take a stab.

Option 1 – ansible-galaxy import (probably easiest)

By adding a ansible-galaxy import command to the CI/CD process, we can trigger galaxy importing the latest release.

Here's an example (thank you @geerlingguy).

Option 2 – Migrate to a Collection

We could migrate this standalone galaxy role to a role in a Collection.

This would the Galaxy /v2 API as opposed to /v1. However, /v1 is by no means deprecated. There is divided opinion on whether migrating to /v2 provides any particular benefit; some folks feel like the release of /v2 was rushed and problematic.

Option 3 – Support build notifications from GitHub Actions

Sadly, Ansible Galaxy only supports build status updates from the proprietary Travis CI JSON payload schema. To my knowledge, this might be the only Option that includes getting Galaxy to accurately show a projects builds as passing/failing.

We could write a reusable GitHub Action that takes facts from a GitHub Action Job, transforms them into the proprietary format, and pushes the JSON payload to Galaxy.

ansible/galaxy#46 (comment)

Option 3 has the most features, and Option 1 is by far the simplest to implement.