The --skip flag not being shown in GitHub PR after upgrading to 9.1.0
Closed this issue · 5 comments
Bug report
After upgrading Chromatic CLI from 9.0.0 to 9.1.0, when PR CI builds on our project call the --skip flag on chromatic, the skip message would not be sent to the UI Test check on the PR. This prevented people from being able to merge their PRs, as the 'UI Test' check was required.
Reverting to 9.0.0 fixed the issue.
Our CI builds are run on AWS CodeBuild.
We just hit this issue, but we're also using the GH action that doesn't support versioning: #797. Now we're in the uncomfortable position of having to remove Chromatic as a required check until the issue is resolved.
We're looking into this issue. For the time being I've reverted our GitHub Action to use v9.0.0 of the CLI.
For my information, what other flags are y'all using? I suspect it may have something to do with the --diagnostics flag which was renamed to --diagnostics-file (or diagnosticsFile with the Action).
@JoshTumath Could you install 9.1.0--canary.855.6905377291.0 and try with that version? That's the canary release for #855 which is the most likely culprit.
Also, did the CLI report that it was skipping the build (i.e. the issue is with tagging the commit as skipped), or did it not skip at all?
@JoshTumath Could you install
9.1.0--canary.855.6905377291.0and try with that version? That's the canary release for #855 which is the most likely culprit.
Sorry for the late reply. We've been looking into it further and don't think it was to do with the 9.1.0 upgrade. That seems to have been a coincidence that the issue started happening then.
Also, did the CLI report that it was skipping the build (i.e. the issue is with tagging the commit as skipped), or did it not skip at all?
Yes the CLI was reporting on our CodeBuild CI logs that the build was being skipped. It seemed the hook that updates the UI Tests status check was somehow being interrupted after that point.
I think it's safe to close this bug report for now and we can reopen it again if we do determine the issue was caused by the 9.1.0 upgrade.
We confirmed with several customers that this issue is not related to the CLI, or at least not with v9.1.0.