UTF-8 BOM character breaks workflow parser

[dogboydog]

Hi all,

Loving GitHub actions and the new workflow_dispatch functionality! I just wanted to raise this issue which caused me some confusion. I now have a workaround detailed in the link at the bottom, but wanted to know the staff and other users’ thoughts on this.

Here is an example patch that will break the parser. It seems to cause unpredictable error messages later in the workflow file (“you have a syntax error at line 15”, etc.)

github.com

dogboydog/manual-workflow-test/blob/084e6017a349363d88303a39542e921a01b59dbe/failed_parse_patch.patch

Index: .github/workflows/quick_build.yaml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- .github/workflows/quick_build.yaml	(revision 976bf688492ab5c161b78bed7282b2d4085c3f18)
+++ .github/workflows/quick_build.yaml	(revision a5762b6b4f2940a46be1b1ee3b87b32d6e54023b)
@@ -1,12 +1,11 @@
-name: Single build and upload
+name: Single build and upload
on:

workflow_dispatch:

inputs:


 logLevel:



   description: 'Log level'





 gitRef:



   description: 'Enter the git ref (branch, commit hash, tag, etc.) to build.'
   required: true





   default: 'warning'

This file has been truncated. show original

I would link to some failed runs but it seems like they disappeared after I stripped out the character myself and GitHub was able to parse the workflow name.

What do you think of this issue? Should the parser strip it out, or is there at least some way the parser can detect it’s presence and give a specific message about it. It seems like it could be safely removed. I know you are not expecting this character but some editors automatically insert it.

There is more information here but I figured it is no longer exactly my initial issue from that thread, so I made a new one. Please forgive any frustration I expressed there as I debugged this issue. Thank you

Can't trigger workflow manually

[weide-zhou]

Hi @dogboydog,

I forked your repository and create a new yaml following your patch file. However, i cannot reproduce the error on my workflow.
For example: https://github.com/weide-zhou/manual-workflow-test/actions/runs/188160858/workflow

I’m not sure 100% follow, let me know if there are any misunderstanding.

The input value will not be added to env, hence, you cannot echo it with $ or $INPUT_, please get it from context, like ${{ github.event.inputs.logLevel }}.

Thanks

[dogboydog]

Hmm odd. There are screenshots of the error in my other thread but I’ll post them here.

image1175×476 73.4 KB

image840×428 49.1 KB

image2199×1466 199 KB

image2305×803 134 KB

Also this pull request from staff from a previous thread involving this issue before I figured out the exact character made the same fix which made my workflow start parsing correctly again:
https://github.com/dogboydog/manual-workflow-test/pull/1/files But I encountered the issue several times after this PR from creating other workflows.

Is it possible GitHub rolled out a fix for this in the last few days? @cschleiden? I can’t get it to happen anymore either, so that’s a good thing. Is there a changelog somewhere that shows bug fixes? I can only find actions to create changelogs by searching.

And yeah I know about the input thing. If you’re talking about test_manual2.yaml, that is an example from my other topic that demonstrates that the environmental variable is not set. But thank you

Edit: I think they might have just rolled out a fix. I’m happy they did! I missed this message in another topic and didn’t realize they were already tracking this issue. So, sorry if this is a duplicate.

And yes, that seems to be a bug in our parser, we should report that error. I’ll file an issue for us to take a look 🙇‍♂️‍♂

[cschleiden]

@dogboydog Thanks for the detailed report. I fixed an issue a bit more than a week ago where we ignore the BOM characters. Let me know if you can still repro this somewhere, happy to take another look :slight_smile:

[dogboydog]

Thanks for replying. I was wrestling with this issue on Sunday the 26th still (as soon as I stripped the BOM out, it starting parsing again), but I just tried to reproduce and I can’t anymore. If you fixed it more than a week ago I’m not sure why I was still seeing it on Sunday, but it seems all good now. Seems totally fixed. Thank you

[paulbizsunny]

Good morning dear, you guys are working hard to make the platform friendly keep it up thank you