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
Update CI pipeline to support installing build-tools from npm #11670
Conversation
build-tools/packages/build-cli/src/commands/generate/buildVersion.ts
Outdated
Show resolved
Hide resolved
| @@ -21,6 +21,10 @@ parameters: | |||
| - default | |||
| - skip | |||
| - force | |||
| - name: buildToolsVersionToInstall | |||
| displayName: Fluid build tools version (default = installs version in repo) | |||
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.
should it default to not repo? the repo version does add non-trivial time to the pipeline.
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.
Once the build tools are baked, I'll update the default for main. In lts it'll default to npm, but main for now will use the in-repo version.
|
This commit is queued for merging with the |
This is the same as #11670 with some minor adjustments for the lts branch. Most notably, it defaults to the latest npm version of the build tools instead of the in-repo version.
| npm ci | ||
| popd | ||
|
|
||
| - ${{ if ne(parameters.buildToolsVersionToInstall, 'repo') }}: |
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.
Curious if we use an if-equal above and an independent if-not-equal here over an else for some reason?
This is the same as #11670 with some minor adjustments for the lts branch. Most notably, it defaults to the latest npm version of the build tools instead of the in-repo version.
The previous change in #11670 was incomplete. It did not properly pass through the build tools location from the ADO UI all the way to the right places. This change corrects that. I tested by manually running a build with the "next" value for the build tools source, and verified that the prerelease (tagged `@next`) version was installed.
The previous change in microsoft#11670 was incomplete. It did not properly pass through the build tools location from the ADO UI all the way to the right places. This change corrects that. I tested by manually running a build with the "next" value for the build tools source, and verified that the prerelease (tagged `@next`) version was installed.
We use our homegrown build-tools to do some tasks in our CI pipelines. It's helpful to be able to install the local in-repo version of the tools in most cases, but sometimes we want to install from npm instead. This change enables us to control the version of the build tools that are installed via a pipeline variable that's set when the pipeline is run.