Custom labels for readability and CLI output

[Fishbowler]

Proposed Changes

Builds on the work of @SuperRoach in #1238

Adds a label attribute to a number of commands. This:

• adds readability to the file as to the purpose of a particular step (especially relevant for tapping on points or vague element selectors)
• is also returned in the description() method of those commands to be displayed in the CLI output.

I'm a first-timer, so have some outstanding questions:

• Does this need a Docs PR ready for merge before this can be merged?
• Is there additional testing that could/should be done?
• Is partial support for label acceptable, so long as it's documented?

Testing

• Extended Unit tests
• Added new Integration test
• Tested locally by amending my own flows (the reason I'm working on this 😉)

Issues Fixed

Solves #1229 and provides a workaround for #1226

[DannyCork]

Can we get this reviewed please? Many thanks

[igorsmotto]

Hi there @Fishbowler! Thanks for taking the time to create a Pull Request! Let me check internally with the team regarding your questions and I'll back to you.

Also, I'm curious, Why did you implement only for a partial set of commands? (Instead of all of them?)

[Fishbowler]

I did all the ones that seemed sensible. But I've only got my single point of view & use cases. I asked the question since it might go against some design values, rather than being "obviously incomplete".

[igorsmotto]

Hey @Fishbowler! Thanks for your answer - I was wondering if you had found any technical challenges but it seems it was not the case.

I brought this suggestion to the team, and we see this as a big quality-of-life improvement for Maestro users and we want to move forward with this PR.

Now, one thing is that we would love to see this label for all commands. If you're up to implementing it for all the missing commands it would really be awesome, I can offer help with the review, merging, and release process of Maestro.

This also has the benefit of making it easier to update the documentation: we can make a new page that describes the label and that it works for every command. I can also help with documentation after this PR is ready for merge.

---

Is there additional testing that could/should be done?

Your tests here are already great!

[Fishbowler]

@igorsmotto What are your feelings on the commands that currently don't take parameters, like scroll or back? Make this the first?

[igorsmotto]

@Fishbowler
I believe it makes sense. Since they will be optional.

The only thing to be aware of is that both APIs should work to avoid retro-compatibility issues, e.g.:

- scroll

and

- scroll:
    label: "custom label"

[Fishbowler]

What about keeping support for undocumented (legacy?) formats like

- action: scroll

Currently, this is in my way.

[igorsmotto]

Feel free to ignore those.

[Fishbowler]

@igorsmotto I think this is ready for re-review

[igorsmotto]

That's awesome work! @Fishbowler 🎉

Made some small comments, but everything is looking good.

In the meantime, I'll run this PR against our internal test suite to be extra sure and if everything goes well, we'll be ready to merge it.

[Fishbowler]

Accepted all, and tidied commit history (slightly) 👍

[Fishbowler]

Added a draft PR of some docs to the docs repo.

PR: mobile-dev-inc/maestro-docs#25

Preview: https://github.com/Fishbowler/maestro-docs/blob/abe57ab66ab49c3c9361acaa130ec8ccc2290036/api-reference/labels.md

[igorsmotto]

Hi there, @Fishbowler!

After our internal testing, we're thrilled to report that everything has passed with flying colors. Therefore, your PR has been given the green light, and we're planning to merge it ASAP.

I will take care of both this PR and the docs PR.

One important note is that this change will wait until the next release (1.33.0). The exact release date is still TBD, but your name will be in the Changelog when it finally arrives.

Your efforts have truly made a difference! We deeply appreciate it!

[igorsmotto]

Hey, @Fishbowler

Given that this is your user fork I don't have permission to edit this PR and resolve conflicts with the main branch

We have 3 options here:

1. Give me permission with select Allow edits from maintainers. docs here so I can push the commit
2. Have a PR building with this work with the resolution of conflict PR here. This will remove your author from the main branch history.
3. Cherry-pick this commit and update this branch so I can merge right away

[Fishbowler]

Weird, I've checked and I already had Allow edits from maintainers checked.

I've fast-forwarded my branch to yours, and got all the ✅s - good to go!

[Fishbowler]

Future archaeologists:
This was reverted after some internal problems in Maestro were discovered, then re-added by @amanjeetsingh150 in #1481