treat metadata file differently locally from CI #103
Conversation
There was a problem hiding this comment.
Deleting this for now. The first time the action runs, it'll re-create it!
There was a problem hiding this comment.
I like that, let's us verify it works as expected!
| return { name: b.name, version: b.version }; | ||
| }); | ||
| writeFileSync(metadataPath, JSON.stringify(metadata, undefined, '\t')); | ||
| if (isCI || updateGoldens) { |
There was a problem hiding this comment.
I assume we're ok with the browser versions being slightly off if you're using --filter or --grep with --golden, meaning any old goldens you don't update could've been created by an older browser. There isn't really a way around it without storing the browser info with every png like we'd originally thought about. And it's only an issue locally, not in CI
There was a problem hiding this comment.
Good point, but yeah not worried about it. This stuff is really only useful in CI anyway -- if you're reusing old goldens locally from an old browser... I'm not sure what you're doing. I've almost talked myself into only using this information in CI, period, haha.
|
🎉 This PR is included in version 0.22.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
ghost
added
the
Follow-up from #94 based on some feedback.
When running locally, we don't want it messing with the
.vdiff.jsonmetadata file that was generated by CI and checked into source control. So locally it'll read & write that file from.vdiff/.vdiff.jsonwhich is automatically.gitignore'd. It'll only write it locally when goldens are being re-generated.In CI, it'll reference the metadata file from the root
.vdiff.json, and will always write to it. If modified, it'll get committed with the rest of the golden changes.