Skip to content

Implement e2e tests for export functionality#3506

Open
DuBento wants to merge 28 commits intothought-machine:masterfrom
DuBento:export-tests
Open

Implement e2e tests for export functionality#3506
DuBento wants to merge 28 commits intothought-machine:masterfrom
DuBento:export-tests

Conversation

@DuBento
Copy link
Copy Markdown

@DuBento DuBento commented Mar 24, 2026

This changes introduce small, targeted export test cases. The goal is to use these test for validating upcoming changes to the export logic.

  • Introduced a new please_export_e2e_test build def that is heavily inspired by please_repo_e2e_test but branches away to avoid injecting any base configuration files.
  • Favoured readability by using golden-master tests: for each case we define a test_repo and an expected_repo with the entire files for testing and for validating the export.
  • Non-breaking changes to the generic please_repo_e2e_test were added to accommodate additional logic.

Copy link
Copy Markdown
Contributor

@toastwaffle toastwaffle left a comment

Choose a reason for hiding this comment

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

Let's ensure that each test repo has at least one target that does not get exported (getting it as close as possible to the edge of being exported). You've got quite a few cases here where the expected repo is identical to the test repo, which doesn't prove anything for the "export as little as possible" goal of exporting. Bonus points for making the e2e enforce that the test repo and expected repo are different.

Also, what's the behaviour around comments in BUILD files - is it worth a test case which exposes that?


# # Test go binary target.
please_export_e2e_test(
name = "export_go_binary",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Other than the target being exported moving to a subdirectory, I don't see any behavioural difference between this and export_go_target_with_go_dep

)

# Test outputs export.
please_repo_e2e_test(
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why do you not use please_export_e2e_test here? I think both would be clearer as golden-master tests

)

# Export a target from a repo that preloads a build def.
# This test purposely doesn't use the custom def but checks that the source files are still included.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
# This test purposely doesn't use the custom def but checks that the source files are still included.
# The exported target doesn't use the preloaded build def, but the preloaded build def is still present in the export.

config_override = ""
if include_go:
config_override += "-o plugin.go.gotool:$TOOLS_GO"
tools["GO"] = [CONFIG.GO.GO_TOOL]
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

is this necessary at all?


config_override = ""
if include_go:
config_override += "-o plugin.go.gotool:$TOOLS_GO"
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

can't we just put this in the .plzconfig in the source repo?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants