Fix multibuildpack integration test timeouts (builds #19-22 failures)

[tnikolova82]

Summary

Fixes consistent failures in builds #19-22 where the nodejs multibuildpack integration test timed out after ~920 seconds across all 5 retry attempts.

Problem

The MultiBuildpack/when_supplied_with_nodejs test has been consistently failing since build #19 (Oct 3). Investigation revealed the test was using the default 20-second Eventually timeout, which is insufficient for this heavy Rails 7.2 + Webpacker multi-buildpack scenario.

Why the test fails

1. Heavy multi-buildpack staging (~4-5 minutes):

   • nodejs-buildpack downloads Node 22.23.3, Yarn 1.22.22, Python 3.13.16
   • Yarn install takes ~53 seconds for node_modules (webpack, webpacker, etc.)
   • ruby-buildpack downloads Ruby 3.2.11, Bundler 2.7.2, RubyGems 3.6.8
   • Bundle install processes 78 gems including full Rails 7.2.3 stack
   • Webpacker performs asset compilation

2. Slow app boot time (60-120 seconds):

   • Rails apps with Webpacker need time to initialize
   • Multi-buildpack apps have additional startup overhead
   • The test fixture runs node -v and ruby -v commands on each request

3. Parallel execution resource contention:

   • Tests run with GINKGO_NODES=3
   • Multiple heavy Rails apps deploy simultaneously
   • Limited CF Diego cell resources cause scheduling delays

Build history

Build	Date	Buildpack Commit	Status	Notes
#18	Oct 2-3	bbe2a4be	✅ SUCCESS	Last successful build
#19	Oct 3	78d409c5	❌ FAILED	First failure
#20-21	Oct 5	82c4944b, 90ca34cd	❌ FAILED	GINKGO_NODES fix didn't help
#22	Oct 6	7640eb2a	❌ FAILED	serial_flag fix didn't help

The GINKGO_NODES changes (commits 78d409c → 82c4944 → 7640eb2) were unrelated to this timeout issue.

Solution

Extended Eventually timeout to 90 seconds with 2-second poll intervals for all multibuildpack tests:

• ✅ when_supplied_with_nodejs (PRIMARY FIX)
• ✅ when_ruby_is_a_supply_for_the_binary_buildpack
• ✅ when_supplied_with_go
• ✅ when_supplied_with_.NET_Core

Changes made

// Added time import
import (
    "path/filepath"
    "testing"
    "time"  // NEW
    ...
)

// Extended timeout from default 20s to 90s with 2s polling
Eventually(deployment, 90*time.Second, 2*time.Second).Should(Serve(...))

Precedent

This fix follows the exact same pattern proven successful in:

1. Commit d5294b6 (Oct 2, 2026): "Increase Eventually timeout for 3 flaky Docker-backend integration tests"

   • Fixed: Offline/vendor_bundle, Default/custom_gemfile tests
   • Rationale: "Docker platform backend reports container as started before the app process inside has actually finished booting and bound its port"

2. PR Increase JRuby test polling timeout for cflinuxfs5 stability #1140: JRuby test timeout fixes

   • Extended JRuby test timeout to 90s for the same reason

Both commits explicitly state that the default 20s timeout races with slow app boot times under parallel CI load.

Testing

The fix is conservative and low-risk:

• ✅ Only affects the 4 multibuildpack tests (isolated change)
• ✅ Uses proven timeout values (90s) from d5294b6
• ✅ Doesn't change test logic, only wait time
• ✅ No changes to pipeline configuration needed

Expected outcome

• nodejs multibuildpack test will pass consistently
• Other multibuildpack tests gain resilience against timing variations
• No impact on other tests in the suite

Investigation

Full investigation details available in the commit message and local documentation:

• Analyzed builds Perform dummy commit with new user to trigger Dreddbot #18-22 using fly CLI
• Compared resource versions between successful/failed builds
• Examined staging logs showing 4-5 minute deployment times
• Identified test timeout as the root cause (not code changes)

Checklist

• Code changes follow existing patterns (d5294b6, Increase JRuby test polling timeout for cflinuxfs5 stability #1140)
• Commit message is descriptive and explains the problem/solution
• Changes are minimal and targeted
• No breaking changes or API modifications
• Ready for CI testing

Related

• Fixes builds: Gitbot testing continues. #19, Can we add '--retry <num>' to the bundle install calls? #20, run bundler with --retry to avoid network dodginess #21, Add ruby 2.1.2 dependency in bin/package #22
• Related to: commit d5294b6, PR Increase JRuby test polling timeout for cflinuxfs5 stability #1140
• Concourse job: create-cf-infrastructure-and-execute-integration-test-for-ruby