-
Notifications
You must be signed in to change notification settings - Fork 562
feat(fluid-build): Per package Declarative Tasks #24100
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
Conversation
|
FYI, @tylerbutler |
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.
Pull Request Overview
This PR introduces per-package declarative tasks, allowing task definitions to be specified at the package level. It also fixes a hanging spinner issue by returning false when isUpToDate throws an exception.
- Wraps the isUpToDate check in a try-catch block to prevent hanging when an exception occurs.
- Enables lookup of declarative tasks from both package-specific and global fluidBuild configurations.
- Updates error message formatting in task creation for concurrently executed scripts.
Reviewed Changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| build-tools/packages/build-tools/src/fluidBuild/buildGraph.ts | Added try-catch in isUpToDate to avoid hanging builds on errors. |
| build-tools/packages/build-tools/src/fluidBuild/tscUtils.ts | Added a try-catch around require.resolve for typescript, ensuring a clear error on failure. |
| build-tools/packages/build-tools/src/fluidBuild/tasks/taskFactory.ts | Updated getTaskForExecutable signature and refined error message formatting in concurrently command handling. |
Comments suppressed due to low confidence (1)
build-tools/packages/build-tools/src/fluidBuild/tasks/taskFactory.ts:144
- [nitpick] Consider unifying the error message formatting for concurrently commands to ensure consistency with similar error messages across the codebase.
`${node.pkg.nameColored}: Unable to find any tasks listed in 'concurrently' command${taskName ? ` '${taskName}'` : ""}`
|
/azp run Build - protocol-definitions,Build - test-tools,server-gitrest,server-gitssh,server-historian,server-routerlicious,Build - client packages,repo-policy-check |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run Build - api-markdown-documenter,Build - benchmark-tool,Build - build-common,Build - build-tools,Build - common-utils,Build - eslint-config-fluid,Build - eslint-plugin-fluid |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
@curtisman Can you help me understand the use-case? Is there some reason declaring a global task in not sufficient? |
| node.pkg.packageJson.fluidBuild?.declarativeTasks?.[executable] ?? | ||
| declarativeTasks?.[executable]; |
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 if a declarative task is defined in the root of the workspace? How does it interact with the ones declared in the config and those in the individual packages?
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.
For declarative task, it is an override. (which match task dependencies behavior, where the project specific config is an override (except if the override say to add to the global ones.)
| return isUpToDateArr.every((isUpToDate) => isUpToDate); | ||
| } catch { | ||
| // If checking the up-to-date state fails, we assume that the build is not up to date. | ||
| return 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.
We should log the exception and stack if possible.
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.
maybe in verbose or debug trace?
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, verbose.debug would be fine.
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.
Note that the value of this is just to short circuit the build. So, it is ok to just return false, and let the task individually error out later.
| tscUtilLibPathCache.set(tsPath, tscUtil); | ||
| return tscUtil; | ||
| } catch (e) { | ||
| throw new Error(`Failed to load typescript module for ${path}: ${e.message}`); |
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.
Include the stack.
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.
Adding the inner stack here doesn't seem useful to me.... and it will cause it to have two set of stacks, may be we shouldn't add the try catch here to provide a friendlier error message?
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.
changed to amending the existing error message and rethrow (thus keeping the original stack).
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 now. Sorry I misunderstood the flow here.
|
In general, the pattern for the input/output might not be uniform for the whole repo. But it could be per package. In my case though, it would have even nicer to allow regex on the command line to specify the input/output. |
tylerbutler
left a comment
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.
Looks good to me. I'm interested to see this in action once you're using it.
|
/azp run Build - api-markdown-documenter,Build - benchmark-tool,Build - build-common,Build - build-tools,Build - common-utils,Build - eslint-config-fluid,Build - eslint-plugin-fluid |
|
/azp run Build - protocol-definitions,Build - test-tools,server-gitrest,server-gitssh,server-historian,server-routerlicious,Build - client packages,repo-policy-check |
|
Azure Pipelines successfully started running 1 pipeline(s). |
1 similar comment
|
Azure Pipelines successfully started running 1 pipeline(s). |
you can look at this: https://github.com/microsoft/TypeAgent/blob/297ff119c847b804825d5ce55a473163ee2b75db/ts/packages/agents/player/package.json#L45 |
isUpToDate()throw an exception by returning false if it happens.