Skip to content

build: update dev-infra and rework windows native testing#29705

Merged
devversion merged 1 commit intoangular:mainfrom
devversion:variant-2-test
Mar 3, 2025
Merged

build: update dev-infra and rework windows native testing#29705
devversion merged 1 commit intoangular:mainfrom
devversion:variant-2-test

Conversation

@devversion
Copy link
Copy Markdown
Member

@devversion devversion commented Feb 25, 2025

As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:

  • we will still support contributors on Windows, and we believe we will
    be improving and streamlining the experience here
  • we will continue testing the Angular CLI for our Windows users. We are
    aware of the many Windows users using the ng CLI.

What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!


For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows ng CLI testing!
This is what this change mostly does.

Notably, two things are missing here and will be followed up:

  • caching of the e2e tests on Windows is not properly functioning yet.
  • caching of the WSL node modules + nvm is not working properly yet.

Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our rules_js migration.

@angular-robot angular-robot bot added the area: build & ci Related the build and CI infrastructure of the project label Feb 25, 2025
@devversion devversion force-pushed the variant-2-test branch 29 times, most recently from fca0686 to 5d5c743 Compare February 26, 2025 11:07
@devversion devversion force-pushed the variant-2-test branch 6 times, most recently from de4d7be to f9c1fe6 Compare February 27, 2025 09:12
Copy link
Copy Markdown
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

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

Overall I think its good, I didn't comment on a few places where you still have TODOs for finishing documenting and such. But I am good with the overall direction and content of this.


const testProject = join(getGlobalVariable('projects-root'), 'test-project');

// Note: Dist directory is not cleared between tests, as `git clean` doesn't
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

For what its worth, I have seen it locally when I run enough tests

@devversion devversion force-pushed the variant-2-test branch 14 times, most recently from e0c12cf to 0e0f463 Compare February 28, 2025 17:13
['run', 'serve:ssr:test-project'],
/Node Express server listening on/,
{
...process.env,
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Should we just do this once in execAndWaitForOutputToMatch instead?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Potentially, but I suspect there could be a few left where the inserting of process.env is maybe unintended. Let's leave as is for now and revisit when needed?

Copy link
Copy Markdown
Member

@josephperrott josephperrott left a comment

Choose a reason for hiding this comment

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

LGTM overall

As part of go/ng:windows-dev-future, we are changing how our
infrastructure supports Windows build & testing. Clearly:

- we will still support contributors on Windows, and we believe we will
  be improving and streamlining the experience here
- we will continue testing the Angular CLI for our Windows users. We are
  aware of the many Windows users using the `ng` CLI.

What is changing? We are no longer actively working towards a Bazel infrastructure
that supports native Windows building and testing. There are currently
two ways to contribute to Angular on Windows. That is via WSL, or via
e.g. native Windows cmd.exe, with Git Bash on top. We acknowledge that
the latter worked sometimes, but we also realize it very often breaks as
nobody on our team uses, verifies it, and it introduces extra complexity
because Bazel on Windows is quite disconnected from Linux/Mac (e.g. no
sandboxing). Going forward, to improve our team's effectiveness, and
improve our stability guarantees for Windows (and Windows contributors),
we are actively discouraging the use of Git Bash for contributing to
Angular; but instead ask for WSL to be used. I can speak as one of the
few long-term team members that have worked on Windows (without WSL) most
of my time, that WSL is great and the contributing experience is much
smoother and also easier to "guide". It's a positive change because we
won't be suggesting "two ways to contribute on Windows", where in
reality one is very brittle and can break at any time!

---

For testing of the Angular CLI: We will continue to maintain the
capability to cross-compile via Bazel with Windows as the target
platform. This allows us to build the e2e tests for Windows, and run
them natively outside WSL to ensure native Windows `ng` CLI testing!
This is what this change mostly does.

Notably, two things are missing here and will be followed up:

- caching of the e2e tests on Windows is not properly functioning yet.
- caching of the WSL node modules + nvm is not working properly yet.

Other than that, we are seeing very similar timing and results of the
Windows tests, so this change unblocks our `rules_js` migration.
@angular-automatic-lock-bot
Copy link
Copy Markdown

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

action: merge The PR is ready for merge by the caretaker area: build & ci Related the build and CI infrastructure of the project target: minor This PR is targeted for the next minor release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants