Releases not being pulled by Ansible Galaxy about rvm1-ansible HOT 16 OPEN

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

from rvm1-ansible.

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:

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).

from rvm1-ansible.

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).

from rvm1-ansible.

@lpaulmp @thbar @sfgeorge any idea?

from rvm1-ansible.

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?

from rvm1-ansible.

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

from rvm1-ansible.

Some suggestions here too ansible/galaxy#2070

from rvm1-ansible.

@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.)

from rvm1-ansible.

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?

from rvm1-ansible.

@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.

from rvm1-ansible.

Awesome! Thanks!

from rvm1-ansible.

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

from rvm1-ansible.

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

from rvm1-ansible.

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)
...

from rvm1-ansible.

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

from rvm1-ansible.

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.

from rvm1-ansible.