Skip to content

Conversation

cgwalters
Copy link
Collaborator

I think a good pattern is to keep an open (draft) pull request that should fail CI, and verify that it actually does.

It's surprisingly easily to e.g. have CI not actually test the code. In this case we have our "reverse dependency testing" which patches the crate to use the local code, and that could easily not work.

I think a good pattern is to keep an open (draft) pull request
that *should* fail CI, and verify that it actually does.

It's surprisingly easily to e.g. have CI not actually test the
code.  In this case we have our "reverse dependency testing"
which patches the crate to use the local code, and that could
easily not work.
@cgwalters
Copy link
Collaborator Author

Heh well, due to the semantics of where I chose to inject an error, it turns out this causes us to hang indefinitely...which is definitely a bug.

@cgwalters
Copy link
Collaborator Author

---- test_container_var_content stdout ----
thread 'test_container_var_content' panicked at 'called `Result::unwrap()` on an `Err` value: Exporting container

Caused by:
    0: exporting
    1: Fetching manifest
    2: synthetic CI failure', lib/tests/it/main.rs:897:67
stack backtrace:

Success!

@cgwalters cgwalters changed the title Test that CI successfully fails [DNM] Test that CI successfully fails Nov 23, 2022
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.

1 participant