Skip to content

Conversation

@curtisman
Copy link
Member

  • Enable declarative task to be specified per package.
  • Fix hanging spinner if isUpToDate() throw an exception by returning false if it happens.

Copilot AI review requested due to automatic review settings March 19, 2025 23:13
@github-actions github-actions bot added the area: build Build related issues label Mar 19, 2025
@curtisman
Copy link
Member Author

FYI, @tylerbutler

@github-actions github-actions bot added the base: main PRs targeted against main branch label Mar 19, 2025
Copy link
Contributor

Copilot AI left a 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}'` : ""}`

@tylerbutler tylerbutler self-assigned this Mar 31, 2025
@tylerbutler
Copy link
Member

/azp run Build - protocol-definitions,Build - test-tools,server-gitrest,server-gitssh,server-historian,server-routerlicious,Build - client packages,repo-policy-check

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@tylerbutler
Copy link
Member

/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
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@tylerbutler
Copy link
Member

@curtisman Can you help me understand the use-case? Is there some reason declaring a global task in not sufficient?

@tylerbutler tylerbutler requested a review from a team April 7, 2025 22:38
Comment on lines +89 to +90
node.pkg.packageJson.fluidBuild?.declarativeTasks?.[executable] ??
declarativeTasks?.[executable];
Copy link
Member

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?

Copy link
Member Author

@curtisman curtisman Apr 8, 2025

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;
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

Copy link
Member Author

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}`);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include the stack.

Copy link
Member Author

@curtisman curtisman Apr 8, 2025

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?

Copy link
Member Author

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).

Copy link
Member

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.

@tylerbutler tylerbutler requested a review from a team April 7, 2025 22:44
@curtisman
Copy link
Member Author

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.

Copy link
Member

@tylerbutler tylerbutler left a 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.

@tylerbutler
Copy link
Member

/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

@tylerbutler
Copy link
Member

/azp run Build - protocol-definitions,Build - test-tools,server-gitrest,server-gitssh,server-historian,server-routerlicious,Build - client packages,repo-policy-check

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

1 similar comment
@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@curtisman
Copy link
Member Author

Looks good to me. I'm interested to see this in action once you're using it.

you can look at this: https://github.com/microsoft/TypeAgent/blob/297ff119c847b804825d5ce55a473163ee2b75db/ts/packages/agents/player/package.json#L45

@tylerbutler tylerbutler changed the title Fluid-build: Per package Declarative Tasks feat(fluid-build): Per package Declarative Tasks Apr 8, 2025
@tylerbutler tylerbutler merged commit b5ce3f0 into microsoft:main Apr 8, 2025
38 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: build Build related issues base: main PRs targeted against main branch

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants