Description of the feature request
Add support for creating and viewing workflow description.
Use case / for what or how I would use it
A job may have many workflow options. But choosing the right workflow requires long expressive workflow titles or sifting through its step list to determine what the workflow does. It would be great if I could save a short description of what the workflow is intended to do. This would allow other team members to quickly understand what each workflow does. It would also allow teams to identify restrictions on certain workflows. For example, I have workflow that is intended to only run when manually triggered (because for some reason it costs money or whatever). With a workflow description, I could specify something like, “Do not use this workflow in scheduled builds because xyz”.
Thanks for the infos @rolyatwilson & @bootstraponline!
Worth to note that you can actually specify description (even summary) for workflows, it’s fully supported by the bitrise.yml specs! Related docs & section: bitrise/bitrise-yml-format-spec.md at master · bitrise-io/bitrise · GitHub
The description can be edited on the Workflow Editor UI as well.
That said the description right now is only visible in the Workflow Editor. Should we rephrase this #feature-request for the Build Trigger popup specifically? The one @bootstraponline created the mockup for.
1 Like
Yes, sounds good. I didn’t realize workflow description/summaries existed.
1 Like
I am not sure why this has the “Released” tag. The original OP intent is for the people that execute a build to select it - in other words it needs to appear in Build Trigger popup (similar to bootstraponline mockup). It’s more than “add a description to a workflow”, it’s about displaying it too.
You have another ticket for a very complex setup to address Workflow input parameters. But practically, we just need a simple text to describe how to use it. Bitrise is best known for its simplicity, so please, try not to fall into the good old “what the customer wanted” MEME.
Today, we have to keep separate documentation and nobody really “thinks” to look there because they do not even realize that anything changed. A simple (potentially long) piece of markdown text (the description already supports markdown) would go a long way.
The people that build the workflows are not the same people that use the workflows.
