Incorrect return type for `startsWith`?

[Saransh-cpp]

Code of Conduct

• [X] I have read and agree to the GitHub Docs project's Code of Conduct

What article on docs.github.com is affected?

https://docs.github.com/en/actions/learn-github-actions/expressions

What part(s) of the article would you like to see updated?

The docs for startsWith states that it returns a boolean value - https://docs.github.com/en/actions/learn-github-actions/expressions#startswith, but I get an error saying that the returned value is a string (attached below).

I am unsure if the behavior has been updated and the docs are stale, if I am doing something wrong, or if this is a bug. Could someone please help me out with this?

Additional information

The error in GitHub Actions editor -

[welcome[bot]]

Thanks for opening this issue. A GitHub docs team member should be by to give feedback soon. In the meantime, please check out the contributing guidelines.

[cmwilson21]

@Saransh-cpp Thanks so much for opening an issue! I'll triage this for the team to take a look :eyes:

[github-actions[bot]]

Thanks for opening an issue! We've triaged this issue for technical review by a subject matter expert :eyes:

[thyeggman]

Hi! The actions editor treats YAML expressions as if they were strings. Unfortunately we can't parse them yet, which is why you get the error. In any case, your expression should return a boolean when committed and running.

Hope this helps 🙂

[lucascosti]

Thanks for the clarification, @thyeggman!

Because there's no docs change required, I'll close this issue.

[Saransh-cpp]

Thanks for the help, @thyeggman, and @lucascosti! Would it be possible to highlight this behavior of the GH editor somewhere in the docs? Or is it already highlighted, but I missed it? (Due to the misleading warning, I ended up removing this line from all of my user-facing projects and all of the open-source projects I maintain.)

[lucascosti]

Would it be possible to highlight this behavior of the GH editor somewhere in the docs?

🤔 Hmmm, we don't tend to document bug-like behavior in the docs, and this would be tough to mention in the right spots because the issue is rather with the option being set (in this case cancel-in-progress) rather than the behavior of the expression (which we have many that return a Boolean result).

@thyeggman Do you have any thoughts? Is it possible to update the editor to exclude that warning for options that expect a non-string result when provided with an expression?