asyncapi
[High Priority] CI pipeline is failing
The CI pipeline is failing for all the PRs we have. We are blocked. Please look into the reason behind it.
It's a P1 (high) priority task. Please look into it as soon as possible as we are blocked.
okay @princerajpoot20 the issue was in
if-nodejs-pr-testing.yml where -> .number on a null object cauing error (github.event.pull_request.number != '' )
@princerajpoot20 @Sourya07 While checking github.event.pull_request.number works because of truthiness, it's safer and more explicit to check github.event_name == 'pull_request_target' to decide which ref to checkout. This avoids any ambiguity with null values on push events.
@sammy200-ui both approaches seem feasible. Looping in @princerajpoot20 to review.
if-nodejs-pr-testing.yml where -> .number on a null object cauing error (github.event.pull_request.number != '' )
@Sourya07 Can you share the run from where you got this
@princerajpoot20 The workflow PR testing - if Node project was manually disabled -> (you can see the yellow banner in the Actions tab). That's why all PRs are stuck - no status is being reported because the workflow isn't running at all. Additional line 48 has an expression bug (github.event.pull_request.number != '') that should be fixed to prevent future issues when the workflow runs on push events.
@Sourya07 Can you provide me the merged PR link that resolved the issue, or do you mean it got magically fixed?
@princerajpoot20
this was disabled before that why ->CI pipeline is failing
for now it have been enabled
->check it in action tab
this was disabled before that why ->CI pipeline is failing
Don’t you think there must be a reason why we disabled it
Actually from my point of view I thought that it can be issue that’s why I mentioned that . Thanks for your time ☺️
Hi, So investigated https://github.com/asyncapi/website/actions/runs/20127457536/job/57760392927?pr=4703. Other places it seems to be a lint error.
The test start function › should throw an error if no finance data is found was failing on macOS (but passing on Ubuntu) in CI. The test expected fs.readdirSync to be called once, but it was called twice.
Root cause: scripts/index.ts was calling start() at module load time (line 68). When Jest imported the module, start() ran during import, then again when the test called it, causing the double call.
@princerajpoot20 let me know what you think. I am opening a pr to propose solution. Let me know if i missed something.
So I just got to know that there is a newly created duplicate issue (#4732) created, and it seems like multiple people are working on the same thing. We should not have this situation.
Umm… let me see what I can do.
Kinda resolved on the latest PRs. Closing this.
Can reopen if it occurs again.
