Galaxy deploy collection

[staticdev]

Closes #186

[aalaesar]

I noted that this workflow is run at every merge into main.
but for the collection we don't want this.
The ansible-collection build the archive with the content as is and use the version metadata to generate the archive name.
This will break/fail on every commit in main that are not tags. (release_tag won't have the proper value on non tag event)
So we should probably change-the trigger or add-a-new workflow for release on tag only, if possible

[staticdev]

I noted that this workflow is run at every merge into main. but for the collection we don't want this. The ansible-collection build the archive with the content as is and use the version metadata to generate the archive name. This will break/fail on every commit in main that are not tags. (release_tag won't have the proper value on non tag event) So we should probably change-the trigger or add-a-new workflow for release on tag only, if possible

For now I would keep it to check if deployment is ok like this and we can create another issue to improve it if you agree.

[staticdev]

I noted that this workflow is run at every merge into main. but for the collection we don't want this. The ansible-collection build the archive with the content as is and use the version metadata to generate the archive name. This will break/fail on every commit in main that are not tags. (release_tag won't have the proper value on non tag event) So we should probably change-the trigger or add-a-new workflow for release on tag only, if possible

I see @aalaesar, maybe this will happen but I expect it to work. I propose we do a couple of tests as it is. If we get problems every merge I will make a PR to check for new tag. My idea is to try to have as many releases as possible to identify and correct errors more easily also.

[aalaesar]

For testing you can change the condition to trigger the action for every commit in this branch.
So we'll see right away

[staticdev]

For testing you can change the condition to trigger the action for every commit in this branch. So we'll see right away

Fair enough, I just tried that.. current problem is that on the new repo there must be a secret set for Ansible Galaxy:

fatal: [localhost]: FAILED! => {"changed": false, "msg": "A valid ANSIBLE_GALAXY_TOKEN must be set."}

[aalaesar]

Fair enough, I just tried that.. current problem is that on the new repo there must be a secret set for Ansible Galaxy:

fatal: [localhost]: FAILED! => {"changed": false, "msg": "A valid ANSIBLE_GALAXY_TOKEN must be set."}

The secret is still here but it was named GALAXY_TOKEN when we first needed it.
Any way, I'll add it again with the ANSIBLE_ prefix 😄
Nope it needs to be set in the step.

[staticdev]

@aalaesar the problem now it that the namespace is diverging on galaxy.yml from one on repo name.

[staticdev]

@aalaesar I added hardcoded the old namespace and name to test... Now I get:

Error: derr": " [ERROR]: Galaxy import error message: Import Task \"25916\" failed: Invalid\ncollection metadata. 'tag' has invalid format: self-hosted\nERROR! Galaxy import process failed: Invalid collection metadata. 'tag' has invalid format: self-hosted (Code: None)",

There is an ongoing issue with that ansible/galaxy#1563

Workaround: use underscore instead.

After that now I get:

Error: WARNING]: Galaxy import warning message: plugins/modules/run_occ.py:104:1:\nF401 'ansible.module_utils.basic.missing_required_lib' imported but unused\n [ERROR]: Galaxy import error message: Import Task \"25917\" failed:\n'requires_ansible' in meta/runtime.yml is mandatory, but no meta/runtime.yml\nfound\nERROR! Galaxy import process failed: 'requires_ansible' in meta/runtime.yml is mandatory, but no meta/runtime.yml found (Code: None)",

After fixing that:

Warning: rr": "[WARNING]: Galaxy import warning message: plugins/modules/run_occ.py:104:1:\nF401 'ansible.module_utils.basic.missing_required_lib' imported but unused",
    "stderr_lines": [
Warning: [WARNING]: Galaxy import warning message: plugins/modules/run_occ.py:104:1:",
        "F401 'ansible.module_utils.basic.missing_required_lib' imported but unused"
    ],
    "stdout": "Publishing collection artifact '/home/runner/work/ansible-collection-nextcloud-admin/ansible-collection-nextcloud-admin/aalaesar-nextcloud-1.9.2.tar.gz' to default [https://galaxy.ansible.com/api/\nCollection](https://galaxy.ansible.com/api//nCollection) has been published to the Galaxy server default [https://galaxy.ansible.com/api/\nWaiting](https://galaxy.ansible.com/api//nWaiting) until Galaxy import task https://galaxy.ansible.com/api/v2/collection-imports/25918/ has completed\nCollection has been successfully published and imported to the Galaxy server default https://galaxy.ansible.com/api/",

[staticdev]

@aalaesar @wiktor2200 TL;DR it works. Now fixing the errors from ansible-lint, there are a few.

[aalaesar]

Hello there
Well done @staticdev !
I think I might not understand completely how the code behaviour, but it worked ! ( But ansible page display 0 modules...)

So if the namespace and name are now hard coded in the playbook command, we should set the version to 2.0.0 and merge it after #209, once the namespace has been created.

[wiktor2200]

Great work @staticdev! I've left one more small comment (plus confirmation that we won't leak galaxy token), but apart from that LGTM and can be merged. :)

Regarding Galaxy collection, it's weird, maybe counter would be aggregated later, because when you click on Content button you can see 1 role, 1 module and 3 plugins, so all what expected.

[staticdev]

@aalaesar LGTM?

[aalaesar]

@aalaesar LGTM?

The tests have messed up a little bit the tags and the release (no pb it's fixable).
I still want the next release to be 2.0.0 as the collection is a breaking change
When I'll delete the tags 1.9.x, will the release drafter regenerate the release description from scratch or do I have to put back the current text in the draft ?

[staticdev]

@aalaesar LGTM?

The tests have messed up a little bit the tags and the release (no pb it's fixable). I still want the next release to be 2.0.0 as the collection is a breaking change When I'll delete the tags 1.9.x, will the release drafter regenerate the release description from scratch or do I have to put back the current text in the draft ?

Ah, Yeah I messed up. Not drafter fault, I did a couple of releases. I just did a clean up of the tags and releases but we will need to manually do the description to 2.0.0.. One time thing..

[wiktor2200]

Hi @staticdev @aalaesar!
That's not a problem at all :)
My RSS reader has it cached, so I pasted "1.9.0" description to draft :)

[aalaesar]

LGTM

[staticdev]

I see LGTM from @wiktor2200 also so doing it.