-
Notifications
You must be signed in to change notification settings - Fork 27
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
Upload source maps during prod build #2523
Upload source maps during prod build #2523
Conversation
The latest updates on your projects. Learn more about Vercel for Git βοΈ
|
π¦ Next.js Bundle AnalysisThis analysis was generated by the next.js bundle analysis action π€ This PR introduced no changes to the javascript bundle π |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π This looks great so far!
π€ Main feedback is whether we should use the non-prod.developer.hashicorp.com
service in DataDog for non-prod source maps. I think this might be necessary since it's already set up in our config
files!
π§ͺ I'm not as familiar with DataDog, so with the empty PR description I had to poke around a bit to try to test things! Given that in the Vercel logs, line 748 we see this version identifier:
I think we would expect to see source maps uploaded on the developer.hashicorp.com
service with version 70fb5226724a8cca166384645f88e26d950e3f26
... I couldn't find a version 70fb5226724a8cca166384645f88e26d950e3f26
in that service, but I could find it fornon-prod.developer.hashicorp.com
, although without source maps (as far as I can tell):
That being said, I might be going about testing in a weird way here, very open to other approaches!
Thinking out loud, but could we (temporarily) intentionally throw an error on a specific page in this PR? I think then we could use that page to test both that we're uploading source maps (which seems to be confirmed by the Vercel logs in this PR), and that we're uploading them in a way where we can trace them back when an error happens.
scripts/upload-source-maps.ts
Outdated
|
||
try { | ||
const status = execSync( | ||
`DATADOG_API_KEY=${DATADOG_API_KEY} npx @datadog/datadog-ci sourcemaps upload .next/static/ --service=${SERVICE} --release-version=${LATEST_SHA} --minified-path-prefix=${PATH_PREFIX}` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noticed this error in the Vercel build logs:
It seems like "running datadog-ci
within the git repo" should in theory be happening, but isn't working as expected π€ It seems like we can manually set the relevant info ourselves... but I am curious why the DataDog CLI doesn't seem to be finding any git remotes... maybe a Vercel thing? π€· I'm lost π¬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is coming up it's trying to get metadata. From the DD docs.
If you run datadog-ci sourcemaps upload within a Git working directory, Datadog collects repository metadata.
More info here: https://github.com/DataDog/datadog-ci/tree/master/src/commands/sourcemaps#link-errors-with-your-source-code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: the error went away when I added the flag --disable-git
on my test branch
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet, glad the error's gone! π
In a perfect world, I think if we could resolve the issue without the --disable-git
flag, then we might be able to link back to the source repo (screenshot from here):
Feels kinda unnecessary though... the setup you've done to get the above link working feels like it's the really valuable thing here π Finding out how to get DataDog's git
stuff to work feels like something we can tack on later as a very optional enhancement if we really want to π
scripts/upload-source-maps.ts
Outdated
// https://github.com/DataDog/datadog-ci/tree/79c0edce658c54001327e8bbb3f1030e8f4ccc93/src/commands/deployment | ||
// https://app.datadoghq.com/source-code/setup/apm?env=preview&service=developer.hashicorp.com&version= | ||
// try { | ||
// const DD_GIT_COMMIT_SHA = process.env.DD_GIT_COMMIT_SHA | ||
// const DD_GIT_REPOSITORY_URL = process.env.DD_GIT_REPOSITORY_URL | ||
|
||
// const gitInfo = `--source-control-provider=git --source-control-repository-url=${DD_GIT_REPOSITORY_URL} --source-control-revision=${DD_GIT_COMMIT_SHA}` | ||
|
||
// const deployStatus = execSync( | ||
// `DATADOG_API_KEY=${DATADOG_API_KEY} npx @datadog/datadog-ci deployments create ${gitInfo} --service=${SERVICE} --env=${process.env.VERCEL_ENV}` | ||
// ) | ||
|
||
// deployStatus | ||
// .toString() | ||
// .split('\n') | ||
// .forEach((line) => { | ||
// console.log(line) | ||
// }) | ||
|
||
// console.log('Deployment created successfully') | ||
// } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π§Ή Seems like we can remove this commented code, unless it's here for testing!
EDIT: just looked at commit history, realized this might be related to the deployment existing in the non-prod
service rather than prod
π
scripts/upload-source-maps.ts
Outdated
if (process.env.VERCEL_ENV === 'development') { | ||
return | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
π§ͺ I feel like it could be good to have a way to confirm that the basics of source maps are working locally... maybe when VERCEL_ENV
is development
, we could take on the optional --dry-run
parameter and leave everything else the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what do you mean by working locally? that we can test uploading them to datadog locally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
More just to see that datadog-ci
picks up on the *.map
files, and that they're removed after the script runs! I believe the --dry-run
flag will mean source maps aren't uploaded. Definitely feels optional π
Handing off this PR to @heatlikeheatwave. As the original PR was more of a pair programming proof of concept to get DD source map working in prod. Heat has a few more things they are going to try. But we now have a working POC. π |
@zchsh Tested out your idea (to throw intentional error in preview and track in |
62ad731
to
0db18a6
Compare
5ed8ce1
to
f1bc827
Compare
Co-authored-by: Zach Shilton <[email protected]>
β¦dev or when VERCEL_ENV is undefined
f1bc827
to
9590a40
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
β Testing steps working as expected! Looks great π―
π Relevant links
ποΈ What
postbuild
step to unminify RUM errorsVERCEL_ENV
isundefined
(as it will be for anyone populating local env vars from Vercel)π€· Why
π οΈ How
_next
andstatic
.π§ͺ Testing
Additional testing to confirm there are no sourcemaps
.map
to the end of the filename or visit https://dev-portal-git-rn-featbuild-source-maps-during-deploy-hashicorp.vercel.app/_next/static/chunks/3652-2ac327b032073ad3.js.map?dpl=dpl_BRMFdS4zMDHxDYVjSL4QXgtb7dbX