Support local buildpacks and meta-buildpacks in libcnb-test #666
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The test runner has been modified to support a `BuildpackReference::LibCnbRs(BuildpackId)` variant which represents a buildpack (and any of it's dependencies) within the workspace that needs to be compiled for testing. This is similar to `BuildpackReference::Crate` but also supports meta-buildpacks.
edmorley
reviewed
Sep 4, 2023
* Renamed `LibCnbRs` to `WorkspaceBuildpack` * Renamed `Crate` to `CurrentCrate` * Updated CHANGELOG.md and doc example
edmorley
reviewed
Sep 11, 2023
|
Update: This is on my short list for this week for a review. I should get to this tomorrow. |
colincasey
commented
Sep 12, 2023
Malax
requested changes
Sep 14, 2023
* updated error enum names * removed need for wrapper struct for packaged buildpacks
edmorley
reviewed
Sep 18, 2023
Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: Ed Morley <[email protected]>
Co-authored-by: Ed Morley <[email protected]>
* main: Ignore file support when finding buildpacks (#673) Apply rustfmt to README example (#676) Update example `cargo libcnb package` log output in READMEs (#675) Add CLI usage help output to libcnb-cargo README (#674) Fix lint errors with Rust 1.73 (#672) Include README.md in lib.rs (#667) # Conflicts: # CHANGELOG.md
Malax
approved these changes
Sep 20, 2023
* updated error enum from `PackageTestBuildpackError` to `PackageBuildpackError` * added newline to Cargo.toml
This was referenced Oct 26, 2023
edmorley
added a commit
that referenced
this pull request
Nov 2, 2023
…sts (#715) The `#[should_panic]` annotation allows marking tests that are expected to panic. It accepts an `expected` field which allows for substring matching against the panic message. `panic::catch_unwind` allows doing something similar, but requires a lot more boilerplate. However, it can be used in cases where the panic message contains dynamic values and substring matching isn't adequate for the purpose of what the tests intends to test. In general I believe we should prefer `#[should_panic]` and only use `panic::catch_unwind` when it benefits the test. I've added this recommendation to the top of the integration tests file, and updated several of the tests to follow it. Notably: - For the tests `address_for_port_when_container_crashed` and `app_dir_invalid_path`, the tests now uses `panic::catch_unwind` allowing the assertions to match against the whole dynamic message, improving coverage. - For `expected_pack_failure_still_panics_for_non_pack_failure`, the test has been switched back to using `#[should_panic]` (as it was before #666), since the purpose of the test is not to check the full error message of that specific failure mode, but instead to confirm that a non-pack failure isn't marked as a success when using `.expected_pack_result()`. See: https://doc.rust-lang.org/book/ch11-01-writing-tests.html#checking-for-panics-with-should_panic https://doc.rust-lang.org/std/panic/fn.catch_unwind.html https://doc.rust-lang.org/std/panic/struct.AssertUnwindSafe.html
edmorley
added a commit
that referenced
this pull request
Nov 2, 2023
Improves the integration test coverage in preparation for fixing #666, so as to (a) reduce the size of that PR, (b) make it easier to see the before/after of the error output. GUS-W-14416222.
edmorley
added a commit
that referenced
this pull request
Nov 7, 2023
After #666, incorrect error messages were shown for failures that occurred during buildpack compilation packaging, since the handling in `TestRunner::build_internal` used the wrong message text, plus didn't include the error struct in the `panic!` string. These have been fixed, plus display representations added to all of the new error variants. In addition, the usages of `assert!` and `.unwrap()` in functions that return `Result` have been replaced with new error enum variants. The change in output can be seen in the new tests added by #717. There is one last scenario that doesn't yet have a test - the testing of the cross-compilation output itself. However, I'll add that separately, since it's going to be more complex to test / there are a few different options that we'll need to choose between. Fixes #704. Fixes #709. Fixes #710. GUS-W-14395170.
edmorley
added a commit
that referenced
this pull request
Nov 16, 2023
Since `pack::BuildpackReference` is an internal-only type (not to be confused with the public `build_config::BuildpackReference`), and the `From<&TempDir>` implementation is unused since #666. GUS-W-14502304.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The test runner has been modified to support a
BuildpackReference::LibCnbRs(BuildpackId)variant which represents a buildpack (and any of it's dependencies) within the workspace that needs to be compiled for testing. This is similar toBuildpackReference::Cratebut also supports meta-buildpacks.This PR replaces #590 and should be easier to review now that similar refactorings from that PR have been incorporated into the codebase.