Skill fails with "crash" (unknown cause)

[XertroV]

My first few times running the skill didn't produce log outputs and basically just said "crash". No slack msgs, or anything that I could see in app.atomsit.com

Example: https://go.atomist.com/log/AMQ95ELE5/5d698096-62a2-45d2-a45b-43a0f4020628/7gKAzZ66h45keRtqfhTIK

After seeing #16 I thought maybe the path of my dockerfile _docker-dev/Dockerfile was an issue. When I copied the Dockerfile to the root of the repo, the skill started working (though was failing despite it working for me with docker build).

After fixing the dockerfile in repo base path (mkdir /src -> mkdir -p /src) the build failed again for the same reason, so it is using the Dockerfile in _docker-dev/Dockerfile, which was confirmed in the next build.

In most recent run I removed the extra Dockerfile I created and it seems to be working okay: https://go.atomist.com/log/AMQ95ELE5/a90fd51c-a1ef-4a2a-8da1-9996a4bf9485/R5QlpbC7DRR8XSxcYpuNk

Anyway, so not sure this requires any action, but was really weird

---

I also had a possibly unrelated crash for no apparent reason here: https://go.atomist.com/log/AMQ95ELE5/d50971f5-712b-46b4-934c-15758cc7e418/qPqrvYOIfKHEVRC7yBoBk (halfway through installing gems)

[XertroV]

Screenshots:

Didn't see this last time I looked at this log entry:

7678c276-3157-4ec6-b989-d2a60241764c

[cdupuis]

@XertroV, thanks for raising those. I see that your docker build is now running. Is that correct?

The fact that _docker-dev/Dockerfile didn't work but ./_docker-dev/Dockerfile did is super strange. I'll dig into this.

@dansmithy @neilprosser any idea why Max sees that yellow banner about the log data not being available?

[XertroV]

I see that your docker build is now running.

Yup

I forgot I updated the path from _docker-dev/Dockerfile to ./_docker-dev/Dockerfile, but I just tried changing it back and it's working, even on the commit that was failing before: https://go.atomist.com/log/AMQ95ELE5/e961580b-2b52-475f-b9cb-50d4d9fd89e2/mXWZg0JJMnCa6huymq2fk

[XertroV]

any idea why Max sees that yellow banner about the log data not being available?

So refreshing that page doesn't produce the error message again. I think that might be unrelated; opening up multiple tabs (of different logs) at the same time wouldn't have any weird effects would it?

[neilprosser]

That's interesting. The value it's using for the ID parameter which is causing the error is grabbed from the URL. I wonder whether there's a timing issue which means it's not present for some reason when we make the GraphQL call? We definitely shouldn't be issuing that query if the ID is nil, it's never going to work.

Different tabs shouldn't make any difference but worth bearing in mind if we're struggling to figure out the issue!

The correlation ID mentioned in the screenshot is 7678c276-3157-4ec6-b989-d2a60241764c.

[XertroV]

So I can't replicate either problem:

• changed dockerfile path as above, everything seems working on all commits I've tried ¯\_(ツ)_/¯
• can't make a yellow box show up again, tried opening tabs like: all logs in different tabs quickly, the same log a whole bunch, and just refreshing a single tab. I've only seen it twice: the second time (sent a screencap of it to cdupuis) was when a build was running, which makes me think maybe a race condition of some kind, depending on how graphql works, but that doesn't make much sense given the first one (in the comment above) was freshly opened and the job had long since stopped.

[cdupuis]

@XertroV, we are tracking the yellow banner issue elsewhere (closed source repo).

I'm going to close this issue here. Please feel free to re-open or create new ones when you see issues.

[XertroV]

@cdupuis np, thanks, and will do 👍