Go-github: github actions date not getting parsed by go-github

[geekodour]

github actions log:

19:45:30 main.go:110: parsing time ""8/18/2019 7:44:51 PM"" as ""2006-01-02T15:04:05Z07:00"": cannot parse "/2019 7:44:51 PM"" as "2006"
##[error]Docker run failed with exit code 1

this is on line 110, github.ParseWebHook , it's working with any other payload if I just use it from a regular curl command. but it's failing when used with GithubActions.

data, err := ioutil.ReadFile(cmClient.inputFilePath)
if err != nil {
    log.Fatalln(err)
}
// Parsing event.json.
event, err := github.ParseWebHook("issue_comment", data)
if err != nil {
    log.Fatalln(err)
}

data == issue_comment payload

not sure if this is a github action issue or go-github issue. how can i help to resolve this?

[geekodour]

@gmlewis any idea?

[gmlewis]

You said that regular curl works... can you please provide an example of the response you get from curl?
Then we can look at how this repo is parsing that response and figure out what is going on.

[geekodour]

@gmlewis
this is the normal payload we're getting from the github api:
https://developer.github.com/v3/activity/events/types/#webhook-payload-example-14

the format is the exact same, but with the new github action it seems to be modifying the date I think.

[geekodour]

for a temporary fix for this issue when using with the new github action was provided by @VladMasarik ,

// Temporary fix for the new Github actions time format. This makes the time stamps unusable.
txt := string(data)
reg := regexp.MustCompile("(.*)\"[0-9]+/[0-9]+/2019 [0-9]+:[0-9]+:[0-9]+ [AP]M(.*)")
txt = reg.ReplaceAllString(txt, "$1\"2019-06-11T09:26:28Z$2")
data = []byte(txt)
log.Println("temp fix active")
// End of the temporary fix

[VladMasarik]

When we were using "previous" version of Github actions, the one where workflow was not described in .yaml files, the time stamp inside event.json file was following:
"created_at": "2019-06-11T09:26:28Z"
However, after a the update the timestamp was following:
"created_at": "8/18/2019 7:44:51 PM"

[geekodour]

@parkr might have some inputs?

[gmlewis]

Just to clarify, we have two things here... the actual response from the GitHub Developers API v3 and the go-github package (this repo).

When you say the "previous" version of GitHub actions, which of the two are you talking about?
If it is the latter, I know that we had a PR recently that changed the type of a timestamp to time.Time... but I want to verify if that's what we are talking about, please.

[gmlewis]

Please take a look at https://github.com/google/go-github/pull/1179 and let me know if that is relevant.

[geekodour]

"previous" version of GitHub actions

So github actions migrated from HCL to YAML syntax and had a lot of different changes with it.
https://help.github.com/en/articles/migrating-github-actions-from-hcl-syntax-to-yaml-syntax

When I was using go-github whith the GitHub Developers API v3 payload (event.json file in github actions) in the previous github actions (HCL Syntax) everything was working fine. After github rolled out the new github actions (YAML syntax) the same code no longer works. (format of event.json is not the same anymore)

event.json is a normal GitHub Developers API v3 payload. but with the newer github actions this payload seems not to be compatible with go-github .

About #1179 ,
https://github.com/google/go-github/blob/d77805f8bd2397c4e05eb160a78f92d89b1168dd/github/timestamp.go#L17

I don't think #1179 is causing this.

PS. The HCL syntax/YAML syntax does not make a difference in our context, i just used them to signal previous and the newer version of github actions

[parkr]

Do you have a diff of the two JSON files, before vs after?

[VladMasarik]

The #1179 is fairly similar to our case. However, instead of UNIX epoch integers, webhook payload in our case, is using this format "created_at": "8/18/2019 7:44:51 PM"

[geekodour]

Oh yes, you're correct @VladMasarik , this definitely looks related to #1179

[gmlewis]

Just FYI - a Timestamp is a time.Time:
https://github.com/google/go-github/blob/master/github/timestamp.go#L13-L19

So you should be able to format it any way you wish.

[VladMasarik]

previous working
current broken parsing
I am not sure if diff is useful here, as the webhook JSON is from two different repositories

Does 8/18/2019 7:44:51 PM count as timestamp as well?

[gmlewis]

Hmmm... I remember that #1179 was created because the format changed.

I wonder if we need to be able to support both types of formats when parsing the timestamps?

(The other option might be for you to use the version of this repo before #1179 which would be:
https://github.com/google/go-github/releases/tag/v25.1.3 )

[ericsciple]

@VladMasarik sorry about the regression. The timestamp from the event data was unintentionally getting mutated. The fix is merged into the production branch and should roll out with tomorrow's hotfix train.

[krasi-georgiev]

The linked PR seems to be for a completely different api.

The problem is not with the go-github module, but the /github/workflow/event.json file that is generated by github actions.
https://developer.github.com/actions/creating-github-actions/accessing-the-runtime-environment/

The github api clearly shows that the expected date format returned by the github api is:
"created_at": "2011-04-10T20:09:31Z"
https://developer.github.com/v3/issues/events/

but the date format in the json file generated by the github action is
"created_at": "8/18/2019 7:44:51 PM"

That is why the go-github json parsing fails with:

data, err := ioutil.ReadFile("/github/workflow/event.json")
github.ParseWebHook("issue_comment", data)

[krasi-georgiev]

@ericsciple thanks for the update

[gmlewis]

So... can this issue be closed for this repo?

[srvaroa]

@ericsciple it looks like the actions event payloads still carry the old format, can you confirm whether the fix was rolled out?

[ericsciple]

@srvaroa sorry for the delay. The deployment rolled out to the first ring, but has not progressed further yet. My guess is it will deploy to the rest of the accounts tomorrow or Friday. I'll touch base with the folks driving the deployment tomorrow. Lots of relevant folks are at an all day event again tomorrow, so might be friday.

[srvaroa]

Sorry for the spam, I didn't realize I was referencing this issue from the (WIP) commit :sweat:

[ericsciple]

@VladMasarik @srvaroa the fix has rolled out everywhere now.

We tried to roll it out yesterday, but hit a snag during the deployment. Done now.

[srvaroa]

Thanks @ericsciple! I verified on a test repo and I do get the expected timestamp format.

[gmlewis]

Closing.