-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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
feat(gatsby): Store site metadata #26162
Conversation
Gatsby Cloud Build Reportusing-styled-components 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 19s PerformanceLighthouse report
|
Gatsby Cloud Build Reportclient-only-paths 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 18s PerformanceLighthouse report
|
Gatsby Cloud Build Reportgatsby-master 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 1m PerformanceLighthouse report
|
Gatsby Cloud Build Reportusing-reach-skip-nav 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 21s PerformanceLighthouse report
|
Gatsby Cloud Build Reportgatsby 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 22m PerformanceLighthouse report
|
Gatsby Cloud Build Reportgatsby 🎉 Your build was successful! See the Deploy preview here. Build Details🕐 Build time: 19m |
serviceName: string | ||
): Promise<string | null> => { | ||
serviceName: string, | ||
ignoreLockfile: boolean = false |
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.
Doesn't look like the new parameter is used anywhere? 🤔
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.
Look at line 81
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 meant from the outside 😅 the getService
call below doesn't seem to leverage it:
const data = await getService(program.directory, `developproxy`)
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.
Oh, that's for me in Desktop! I want to get the data without obtaining a lock
Can we register the site when it gets created as well as part of |
I reckon we could register in |
I've added support for gatsby new. I don't think it makes sense to add it whatever command is run, because quite a lot of commands don't require to be run in the context of a local gatsby site. It might make sense to add it for |
|
@KyleAMathews @mxstbr OK, it now registers on |
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.
Overall LGTM, one clarification comment inline but that shouldn't be blocking! 👍
await createServiceLock(program.directory, `metadata`, { | ||
name: program.sitePackageJson.name, | ||
sitePath: program.directory, | ||
lastRun: Date.now(), |
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.
Is there a reason why this doesn't include pid
, but the develop one does? I'm assuming this doesn't store the pid since it's not a long-lived process, but just wanted to clarify!
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.
Yup, exactly. I only include the pid in case I need to kill the process from Desktop.
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.
It doesn't harm us to keep it consistent and always add a pid, right? Do we also want to keep track of which method it is? (build/develop)
Does it make sense to add a typescript type for it?
Moving it to core-utils would solve this as well.
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.
@wardpeet We can't, because the calling process might not always be the actual build process. We use it in Desktop to write the metadata for sites that we have manually added.
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.
Is there a blanket cleanup necessary for cleaning up these locks if someone sends a SIGINT
at a certain time that results in stale lock files lying around?
@sidharthachatterjee Apparently the lockfile library handles that itself. |
@ascorbic Okay, that’s great then. |
@sidharthachatterjee Added the log |
eb0a176
Store pid Allow lockfile to be ignored for services that don't need to be running Get correct port for running service Add last run time init site info in gatsby new Store metadata on build Make getService generic so we can avoid casting Log exception
b74d996
to
cfa0974
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.
I've added some small cleanup tasks.
I only see you writing to the metadata file. Does gatsby desktop removes things from the metadata file? Mostly concerned about keeping pids inside the metadata when the process stopped.
@@ -9,10 +9,11 @@ import isValid from "is-valid-path" | |||
import sysPath from "path" | |||
import prompts from "prompts" | |||
import url from "url" | |||
|
|||
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" |
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.
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" | |
// TODO make service-lock export from gatsby-core-utils | |
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" |
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.
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 see, thanks. I'll create a ticket for me to fix that
const sitePath = sysPath.resolve(rootPath) | ||
|
||
const sitePackageJson = await fs | ||
.readJSON(sysPath.join(sitePath, `package.json`)) | ||
.catch(() => { | ||
reporter.verbose( | ||
`Could not read "${sysPath.join(sitePath, `package.json`)}"` | ||
) | ||
}) | ||
|
||
await createServiceLock(sitePath, `metadata`, { | ||
name: sitePackageJson?.name || rootPath, | ||
sitePath, | ||
lastRun: Date.now(), | ||
}).then(unlock => unlock?.()) |
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.
Could we move this to a function so it's more clear what this does and why we need it? Maybe worth to move it into core-utils?
/**
* the metadata file is used in gatsby desktop to discover which projects are created for gatsby
*/
function saveProjectToMetadataFile() {}
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.
Yeah, though it would still need most of the same props. e.g. it won't always want to save the pid or update the lastRun (e.g. if it's being called from Desktop)
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.
those values could be nullable/undefined maybe?
@@ -36,6 +36,7 @@ import { | |||
markWebpackStatusAsPending, | |||
markWebpackStatusAsDone, | |||
} from "../utils/webpack-status" | |||
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" |
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.
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" | |
// TODO make service-lock export from gatsby-core-utils | |
import { createServiceLock } from "gatsby-core-utils/dist/service-lock" |
await createServiceLock(program.directory, `metadata`, { | ||
name: program.sitePackageJson.name, | ||
sitePath: program.directory, | ||
lastRun: Date.now(), |
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.
It doesn't harm us to keep it consistent and always add a pid, right? Do we also want to keep track of which method it is? (build/develop)
Does it make sense to add a typescript type for it?
Moving it to core-utils would solve this as well.
console.error( | ||
`Looks like develop for this site is already running. Try visiting http://localhost:8000/ maybe?` | ||
`Looks like develop for this site is already running. Try visiting http://localhost:${port}/ maybe?` |
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.
👍
import { | ||
createServiceLock, | ||
getService, | ||
} from "gatsby-core-utils/dist/service-lock" |
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.
import { | |
createServiceLock, | |
getService, | |
} from "gatsby-core-utils/dist/service-lock" | |
// TODO make service-lock export from gatsby-core-utils | |
import { | |
createServiceLock, | |
getService, | |
} from "gatsby-core-utils/dist/service-lock" |
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'll approve, would be nice if you could look into moving things to core-utils in another PR
I just tried to push a commit that would do just that. Oops! |
Store pid Allow lockfile to be ignored for services that don't need to be running Get correct port for running service Add last run time init site info in gatsby new Store metadata on build Make getService generic so we can avoid casting Log exception Co-authored-by: gatsbybot <[email protected]>
This creates a metadata file in the config directory, which allows reverse lookup to find the site's path. This is so that Desktop can iterate the directory to discover all sites on the user's drive.