Open mgeier opened 5 years ago
Yes it's likely a problem if CircleCI is set up both places. The redirector just looks at the status update on GitHub and appends a URL. So if your fork's build pushes a status update after (or instead of) the main repo's CircleCI build, it will point to that one:
https://github.com/larsoner/circleci-artifacts-redirector/blob/master/index.js#L13-L20
PR welcome to improve the logic if you know how, I'm not sure how to differentiate the two but there is probably a way to do so
Well the strange thing is that the CircleCI job seems to be running on the fork, even though the PR was created on the main repo. I would have expected it to run on the main repo. I guess normally this doesn't happen if the fork doesn't have CircleCI setup, which is probably the more common case anyway (but I think it's very useful for contributors to run CI on their fork before making a PR).
Interestingly, the buildId
(which is extracted from context.payload.target_url
) seems to be correct.
Do you happen to know the full content of context.payload.target_url
?
Does it maybe also contain the repo ID?
Getting it from context.payload.repository.id
was wrong in my case.
Here is an example of what I assume was the problematic payload (trimmed):
From which my app produced this payload (presumably the bad one) And this is a payload produced by the app which is correct (in response to a different payload):
That's strange, because the generated URL is the correct one (except probably for the trailing \n
):
"target_url": "https://16-210404706-gh.circle-artifacts.com/0/html/index.html\n"
The (faulty) one that was shown on the Github PR page was https://16-46379698-gh.circle-artifacts.com/0/html/index.html, with repo ID 46379698
, which doesn't appear anywhere in your data ...
Argh yes I pasted the wrong payload. That was the correct one (a response to a CircleCI update that came in less than a second earlier). There are hundreds of them and finding the "right" one is difficult...
In case I need these again: this all happened around 2019-10-10 05:10:49, give or take a second. This was the app's response to the "bad" delivery above:
... and for completeness, here is the other payload that triggered the app to update (at this point not sure which of the two payloads was correct/incorrect):
Thanks a lot for digging up those logs.
Do I understand this correctly: At one point the right information was sent and a short time later (or earlier?) the wrong information was sent?
Would it help just to filter out the wrong one? Would that be possible?
I think the last one is the wrong request (https://github.com/larsoner/circleci-artifacts-redirector/issues/6#issuecomment-540740209).
It has:
"name": "spatialaudio/nbsphinx",
"target_url": "https://circleci.com/gh/mgeier/nbsphinx/16?...",
... where the "name" doesn't match the "target_url".
The correct request would be the very first one:
"name": "mgeier/nbsphinx",
"target_url": "https://circleci.com/gh/mgeier/nbsphinx/16?...",
Here "name" is a substring of "target_url".
I of course don't know if that's generally the case ... but if it is, this should be reasonably easy to detect, right?
Here "name" is a substring of "target_url".
I of course don't know if that's generally the case ... but if it is, this should be reasonably easy to detect, right?
Yeah that seems like it should work
Would you like to try fixing this?
I don't know how to test this and I'm quite bad at JavaScript, so I can't really make a PR for this.
There may be some deeper issue ... I've just created another PR and now CircleCI isn't even showing anything: https://github.com/spatialaudio/nbsphinx/pull/338.
I really don't know if it is usual at all to have CircleCI activated on both the fork and the main repo, but I think it would be a really nice workflow for contributors. Probably the problem is that I control both the fork and the main repo?
I've had other issues with CircleCI when it's enabled on a fork, too.
I can look into improving this at some point but it take me a couple of weeks for me to get to it. I'm also not a JavaScript expert so it takes a bit of thinking and testing for me to get things working.
I think this might actually be due to me using wrong settings on CircleCI, but probably you can help me with it anyway?
Here's an example: https://github.com/spatialaudio/nbsphinx/pull/334
The redirector bot provided this link: https://16-46379698-gh.circle-artifacts.com/0/html/index.html (which leads to a page saying "Build not found").
The correct link would be https://16-210404706-gh.circle-artifacts.com/0/html/index.html.
The reason for the confusion might be that the CircleCI build runs on the account of the fork (https://circleci.com/gh/mgeier/nbsphinx/16) instead of the main repo (which would be https://circleci.com/gh/spatialaudio/nbsphinx/). Both repos have CircleCI configured (maybe that's bad?).
Is there something wrong with my CircleCI settings?