Awx: Aliases for templates/jobs within workflow

Created on 29 Jun 2018  ยท  7Comments  ยท  Source: ansible/awx

ISSUE TYPE
  • Feature Idea
COMPONENT NAME
  • API
  • UI
SUMMARY

Would be great to have job aliases for templates/jobs within workflow which will be shown on workflow pipeline.

Currently only template name is shown. If it is reusable template with many configurable options it's name might not fully describe exact template action performed within workflow.

ui good first issue medium needs_devel enhancement

Most helpful comment

Status update: merging https://github.com/ansible/awx/pull/6291 for adding the identifier field, which does something like this, but targeted toward API clients / the CLI / the Ansible modules.

As a UI request, this still stands.

I would encourage the UI to leverage the identifier field, but the auto-generation of UUIDs when it's blank could give it some challenges (which gets parity between the UI and playbook-created content). I understand if the UI instead goes its own way and adds a different description-like field.

Anyway, I'm taking the API label off because it's not sure to require API changes, and it is oriented towards UI-next.

All 7 comments

Assume this would apply to schedule configurations as well.

This is a duplicate of https://github.com/ansible/awx/issues/1422, although I had no traction for that one and I'll be happy to close that in favor of this one.

Assume this would apply to schedule configurations as well.

I don't follow that. Schedules have a name field already. Yes, schedules and workflow nodes have a commonality that they may contain promotable fields, but this lack of an identifier/name problem is unique to the case of workflow nodes.

Note there is a similar request here https://github.com/ansible/awx/issues/5824

Status update: merging https://github.com/ansible/awx/pull/6291 for adding the identifier field, which does something like this, but targeted toward API clients / the CLI / the Ansible modules.

As a UI request, this still stands.

I would encourage the UI to leverage the identifier field, but the auto-generation of UUIDs when it's blank could give it some challenges (which gets parity between the UI and playbook-created content). I understand if the UI instead goes its own way and adds a different description-like field.

Anyway, I'm taking the API label off because it's not sure to require API changes, and it is oriented towards UI-next.

+1. without this I have to pragmatically created thousands of JT just so my users can understand what the workflow is doing

Hello,
do you have any news about this issue? It would be very useful.

Thanks

@Gianlu and @gpiucco no news yet. Discussions about adding this feature to the new ui have started but nothing definitive has been set. Follow this issue for updates, if you aren't already doing so.

Was this page helpful?
0 / 5 - 0 ratings