Thanks to visit codestin.com
Credit goes to github.com

Skip to content

refactor(builtin): use built-in TEST_TARGET instead of custom BAZEL_TARGET #1503

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

Closed

Conversation

gregmagolan
Copy link
Collaborator

BAZEL_TARGET is not a documented env variable but if a user is relying on it they should be using TEST_TARGET instead.

PR Checklist

Please check if your PR fulfills the following requirements:

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

  • Bugfix
  • Feature (please, look at the "Scope of the project" section in the README.md file)
  • Code style update (formatting, local variables)
  • Refactoring (no functional changes, no api changes)
  • Build related changes
  • CI related changes
  • Documentation content changes
  • Other... Please describe:

What is the current behavior?

Issue Number: N/A

What is the new behavior?

Does this PR introduce a breaking change?

  • Yes
  • No

Other information

@@ -169,7 +169,7 @@ def _nodejs_binary_impl(ctx):

script_path = _to_manifest_path(ctx, ctx.outputs.loader)

env_vars = "export BAZEL_TARGET=%s\n" % ctx.label
env_vars = ""
Copy link
Collaborator

Choose a reason for hiding this comment

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

hmm I am pretty sure we need this in a non-test context somewhere which is why we had to add it. something like running the golden test .accept bin

Copy link
Collaborator Author

@gregmagolan gregmagolan Dec 29, 2019

Choose a reason for hiding this comment

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

Actually that works as with both bazel test //golden/file:test and bazel run //golden/file:test the TEST_* vars are set even in the bazel run case as it is a test target. The usage of TEST_TARGET is for the output

Update the golden file:

            bazel run ${debug ? '--compilation_mode=dbg ' : ''}${
          process.env['TEST_TARGET'].replace(/_bin$/, '')}.accept

which works in both bazel test and bazel run cases.

bazel run //golden/file:test.accept doesn't have the TEST_* vars set but it doesn't need them.

So in our repo we don't need BAZEL_TARGET set for any non-test targets.

I guess the question is if someone else is relying on this and if we should remove it or leave it and document it as a feature?

It can be useful in the run context to know which target is being run. A few others come to mind that would also be useful such as:

  • BAZEL_WORKSPACE (to match TEST_WORKSPACE)
  • BAZEL_BINARY (to match TEST_BINARY)
  • BAZEL_SRCDIR (to match TEST_SRCDIR which is equal to RUNFILES)

Updating Angular to 1.0.0 yesterday I ran into the case where I needed all of these TEST_* vars to load the require.resolve loader patches in a bootstrap script since the bootstrap scripts are now being loaded with --node_options=--require=... and we're in an in-between state where the linker is not yet turned on for jasmine_node_test targets (also it would break on Windows).

/tools/testing/init_node_spec.ts in angular/angular#34589:

if (process.env['TEST_SRCDIR']) {
  // bootstrap the bazel require resolve patch since this
  // script is a bootstrap script loaded with --node_options=--require=...
  const path = require('path');
  require(path.posix.join(
      process.env['TEST_SRCDIR'], process.env['TEST_WORKSPACE'],
      (process.env['TEST_BINARY'] as string).replace(/\.(sh|bat)$/, '_loader.js'), ));
}

import 'zone.js/lib/node/rollup-main';
...

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Ohhhh. The linker relies on TEST_* targets right now which would be a problem for non-test targets:

    const wksp = env['TEST_WORKSPACE'];
    const target = env['TEST_TARGET'];
    if (!!wksp && !!target) {
      // //path/to:target -> //path/to
      const pkg = target.split(':')[0];
      this.packagePath = path.posix.join(wksp, pkg);
    }

    // If under runfiles (and not unit testing) then don't add a bin to target for bin links
    this.noBin = !!env['TEST_TARGET'] && wksp !== 'build_bazel_rules_nodejs' &&
        target !== '//internal/linker/test:unit_tests';

Seems like the right way to go here is to set at least BAZEL_WORKSPACE, BAZEL_TARGET and document them. Possibly BAZEL_SRCDIR and BAZEL_BINARY as well.

@alexeagle
Copy link
Collaborator

https://github.com/angular/angular/blob/1195dabb84b672d48bd80b552dd67c6a5e3f4ac6/tools/size-tracking/size_tracker.ts#L96 seems like maybe a usage of BAZEL_TARGET in a runnable binary

I agree it would be nice to drop the extra variable if we could, we should avoid features that aren't in other languages (why are we different)
would have to wait until we have made a branch for breaking changes (or a release branch for 1.x)

Is there a linker bug already due to that usage of TEST_TARGET?

@gregmagolan
Copy link
Collaborator Author

Yes, it looks like the linker is relying on both TEST_WORKSPACE & TEST_TARGET neither of which are defined for non-test targets.

@gregmagolan
Copy link
Collaborator Author

gregmagolan commented Dec 30, 2019

Tracing it a bit more, those env vars are only used in resolvePackageRelative for tests so that should be fine. For example, in packages/rollup/test/code_splitting/spec.js:

const fs = require('fs');
const {runfiles} = require('build_bazel_rules_nodejs/internal/linker');

describe('rollup code splitting', () => {
  it('should produce a chunk for lazy loaded code', () => {
    const chunks = runfiles.resolvePackageRelative('bundle');

    expect(fs.existsSync(chunks + '/bundle.js')).toBeTruthy();
    expect(fs.existsSync(chunks + '/chunk.js')).toBeTruthy();
  });
});

unless we'd also like that function to work for non-test targets

@gregmagolan
Copy link
Collaborator Author

After the discussion here and a bit of investigation, removing BAZEL_TARGET seems undesirable given that the linker should rely on that instead of TEST_TARGET so that it works with non-test targets. I put up #1517 which should resolve the linker issues with non-test targets.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants