Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chromatic-diagnostics.json no longer includes storybookUrl or webUrl #1053

Closed
drewbrend opened this issue Sep 16, 2024 · 8 comments · Fixed by #1060
Closed

chromatic-diagnostics.json no longer includes storybookUrl or webUrl #1053

drewbrend opened this issue Sep 16, 2024 · 8 comments · Fixed by #1060
Assignees
Labels
enhancement Classification: New feature or request released Verdict: This issue/pull request has been released

Comments

@drewbrend
Copy link

storybookUrl and webUrl are very helpful for integrating into CI. We were using these, but since upgrading from v11.3.2 to v11.10.2 the output to chromatic-diagnostics.json no longer includes these.

These values are still called out in the FAQ for this purpose: https://www.chromatic.com/docs/faq/get-published-storybook-url-via-ci/

Were these removed intentionally? Is there a new way we should be getting these links for the deployed storybook and results?

@drewbrend drewbrend added bug Classification: Something isn't working needs triage Tracking: Issue needs confirmation labels Sep 16, 2024
@codykaup
Copy link
Contributor

Hey @drewbrend! 👋

I just ran a build with that version of the CLI and get both of those fields in the diagnostics file. Would you be able to share a snippet of what you're seeing in your chromatic-diagnostics.json? Do you see any errors in the logs?

@codykaup codykaup self-assigned this Sep 23, 2024
@drewbrend
Copy link
Author

No errors in the logs. Here's what the output chromatic-diagnostics.json looks like. I redacted some things, let me know if you need anything further.

{
"configuration": {
"configFile": "chromatic.config.json",
"projectId": "Project:##########",
"onlyChanged": true,
"zip": true
},
"exitCode": 0,
"exitCodeKey": "OK",
"flags": {
"storybookBuildDir": [
"storybook-static/current"
],
"onlyChanged": "",
"diagnostics": true,
"outputDir": [],
"externals": [],
"onlyStoryFiles": [],
"onlyStoryNames": [],
"untraced": [],
"fileHashing": true,
"interactive": true,
"appCode": []
},
"git": {
"version": "2.39.3 (Apple Git-146)",
"gitUserEmail": "[email protected]",
"uncommittedHash": "",
"commit": "e7ac1771fb85af84d6b02d9f7bcbb8ff92773005",
"committedAt": 1726147370000,
"committerEmail": "[email protected]",
"committerName": "someone else",
"branch": "master",
"slug": "my-repo",
"fromCI": false,
"parentCommits": [
"e7ac1771fb85af84d6b02d9f7bcbb8ff92773005"
]
},
"input": [],
"isOnboarding": false,
"options": {
"fromCI": false,
"inAction": false,
"dryRun": false,
"debug": false,
"autoAcceptChanges": false,
"exitZeroOnChanges": false,
"exitOnceUploaded": false,
"diagnosticsFile": "chromatic-diagnostics.json",
"fileHashing": true,
"interactive": true,
"isLocalBuild": false,
"originalArgv": [
"--storybook-build-dir",
"storybook-static/current",
"--only-changed",
"--diagnostics"
],
"onlyChanged": true,
"zip": true,
"storybookBuildDir": "storybook-static/current",
"storybookLogFile": "build-storybook.log",
"branchName": "",
"configFile": "chromatic.config.json",
"projectId": "Project:##########"
},
"packageJson": {
... copy of package.json here I've removed
},
"packagePath": "/some/path/to/package.json",
"rebuildForBuildId": "66e2eb9845ab52206b4d4600",
"sessionId": "3f3233c3-b7b5-425c-9e65-bfffcb9023ea",
"skip": true,
"startedAt": 1726235757138,
"task": "gitInfo",
"userError": false
}

@codykaup
Copy link
Contributor

I think I see what's happening here. The rebuildForBuildId and skip fields makes me think the CLI picked up that a build already ran successfully on that commit so it skipped everything and no build was created.

Do your logs mention something like that?

@drewbrend
Copy link
Author

Ah okay, I think that makes sense since I was running this several times while working on configuring it in CI.

In my case, we're using the deployments from a branch to add a link to the deployment on a PR so reviewers can check it out.

I can construct the URL in the format of https://{$branchName}--${appId}.chromatic.com, but linking to the specific commit like that path does is nicer.

In the case of a rebuild I'd need to construct this URL instead of getting it from the value in chromatic-diagnostics.json... this isn't a big deal, but if I can rely on that value always being there it would simplify things for me.

Could a skipped run still return the links to the deployment and test results for the last run?

@codykaup
Copy link
Contributor

Yeah that sounds reasonable to me!

In an effort to prevent breaking things for other folks, I'm thinking we add a new field for rebuildForBuild which contains the build information you need. That would mean you'd have to check for that value because it won't exist in the same place in those cases (either build or rebuildForBuild. Does that work?

@drewbrend
Copy link
Author

Yes, I think that'd work for me!

@codykaup codykaup added enhancement Classification: New feature or request and removed needs triage Tracking: Issue needs confirmation bug Classification: Something isn't working labels Sep 27, 2024
@ghengeveld
Copy link
Member

🚀 Issue was released in v11.11.0 🚀

@ghengeveld ghengeveld added the released Verdict: This issue/pull request has been released label Sep 30, 2024
@codykaup
Copy link
Contributor

@drewbrend if you use the latest version, you should get those fields! Remember, they'll be in rebuildForBuild when a rebuild is detected!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Classification: New feature or request released Verdict: This issue/pull request has been released
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants