Skip to content
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

Fix tests after release of Procfile CNB v3.0.0 #800

Closed
edmorley opened this issue Feb 28, 2024 · 0 comments · Fixed by #801
Closed

Fix tests after release of Procfile CNB v3.0.0 #800

edmorley opened this issue Feb 28, 2024 · 0 comments · Fixed by #801
Assignees

Comments

@edmorley
Copy link
Member

edmorley commented Feb 28, 2024

libcnb-test has some tests that make use of the Procfile CNB for testing the start_container() API.

These tests intentionally don't pin to a specific version of the Procfile CNB, so that (a) we don't have to manually update it all the time, (b) we test against what's actually in the builder image and so what people will be using. This is generally fine, since normally there won't be breaking changes in the Procfile CNB that affect our tests.

However, Procfile v3.0.0 was just released with an intentional breaking change to the way that the command vs args are handled.

Specifically, before the Procfile file entry would be set as the process command but now it's set as args.

See:

As a result, CI for this repo is failing with:

---- starting_containers stdout ----
thread 'starting_containers' panicked at libcnb-test/tests/integration_test.rs:502:21:
assertion failed: `(is empty)`
value (unescaped):
$DESIGNATION: line 1: Hello: command not found


value (escaped): `"$DESIGNATION: line 1: Hello: command not found\n"`

eg:
https://github.com/heroku/libcnb.rs/actions/runs/8079052018/job/22073194983#step:8:256

We'll need to update the test here accordingly:

fn starting_containers() {
TestRunner::default().build(
BuildConfig::new("heroku/builder:22", "tests/fixtures/procfile")
.buildpacks([BuildpackReference::Other(String::from(PROCFILE_URL))]),
|context| {
// Using the default entrypoint and command.
context.start_container(
ContainerConfig::new()
.env("PORT", TEST_PORT.to_string())
.expose_port(TEST_PORT),
|container| {
let address_on_host = container.address_for_port(TEST_PORT);
let url = format!("http://{}:{}", address_on_host.ip(), address_on_host.port());
// Retries needed since the server takes a moment to start up.
let mut attempts_remaining = 5;
let response = loop {
let response = ureq::get(&url).call();
if response.is_ok() || attempts_remaining == 0 {
break response;
}
attempts_remaining -= 1;
thread::sleep(Duration::from_secs(1));
}
.unwrap();
let body = response.into_string().unwrap();
assert_contains!(body, "Directory listing for /");
let server_log_output = container.logs_now();
assert_contains!(
server_log_output.stdout,
&format!("Serving HTTP on 0.0.0.0 port {TEST_PORT}")
);
assert_contains!(server_log_output.stderr, "GET /");
let exec_log_output = container.shell_exec("ps | grep python3");
assert_empty!(exec_log_output.stderr);
assert_contains!(exec_log_output.stdout, "python3");
},
);
// Overriding the default entrypoint, but using the default command.
context.start_container(ContainerConfig::new().entrypoint("worker"), |container| {
let all_log_output = container.logs_wait();
assert_empty!(all_log_output.stderr);
assert_eq!(all_log_output.stdout, "this is the worker process!\n");
});
// Overriding both the entrypoint and command.
context.start_container(
ContainerConfig::new()
.entrypoint("echo-args")
.command(["$GREETING", "$DESIGNATION"])
.envs([("GREETING", "Hello"), ("DESIGNATION", "World")]),
|container| {
let all_log_output = container.logs_wait();
assert_empty!(all_log_output.stderr);
assert_eq!(all_log_output.stdout, "Hello World\n");
},
);
let command_output =
context.run_shell_command("for i in {1..3}; do echo \"${i}\"; done");
assert_empty!(command_output.stderr);
assert_eq!(command_output.stdout, "1\n2\n3\n");
},
);
}

@edmorley edmorley self-assigned this Feb 28, 2024
edmorley added a commit that referenced this issue Feb 28, 2024
…801)

Procfile CNB v3.0.0 was just released with an intentional change to the
way that `command` vs `args` are handled in the CNB process type
definition. (Before the `Procfile` file entry would be set as the
process `command`, but now it's set as `args`.)

That change improves the overall UX of running images that use the
Procfile CNB, but is breaking in some lesser used scenarios that
happened to be tested via the `starting_containers` test in this repo.

See:
- heroku/buildpacks-procfile#205 (comment)
- heroku/buildpacks-procfile@v2.0.2...v3.0.0#diff-782521a81713992d3a07e85975d367cfac60afc78583133551efcddc2026bd3eL19-R20

The tests have been updated to account for the new behaviour, and an
additional test added for the "overriding command only" scenario (that
wasn't possible to easily test before due to the way the Procfile CNB
was previously implemented).

Fixes #800.
GUS-W-15139634.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant