Skip to content

Add manifest.yml with increased timeout for Rails72 multibuildpack test fixture - #1179

Merged
tnikolova82 merged 1 commit into
masterfrom
add-manifest-for-rails72-timeout
Oct 9, 2026
Merged

tnikolova82 merged 1 commit into
masterfrom
add-manifest-for-rails72-timeout

Conversation

@tnikolova82

@tnikolova82 tnikolova82 commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Fixes continued failures in builds #23-25 where the nodejs multibuildpack test fails with manifest variable substitution errors and app start timeouts.

Problem Analysis

The Two Issues

Build #25 revealed a manifest variable substitution error on top of the timeout issue:

Expected to find variables: name
FAILED

This error occurs because cf push with name: ((name)) expects a variable definition that doesn't exist.

Root Cause

Switchblade provides the app name via command-line arguments (-n flag), not through manifest variable substitution:

// vendor/github.com/cloudfoundry/switchblade/internal/cloudfoundry/setup.go
args = append(args, "-n", appName)  // Name via CLI flag
args = append(args, "-f", filepath.Join(source, "manifest.yml"))  // Manifest used for other settings

The manifest should not specify a name attribute at all.

The Two-Layer Timeout Issue

Even with the variable error fixed, we still need extended timeouts:

  1. ✅ Test timeout (Gomega Eventually): Fixed in PR Fix multibuildpack integration test timeouts (builds #19-22 failures) #1178 - extended to 90s
  2. ✅ CF app start timeout: Fixed in this PR - extended to 180s via manifest

The Rails 7.2 + Webpacker app takes longer than 60 seconds to boot:

  • Rails framework initialization
  • Webpacker asset loading
  • Database connections
  • Multi-buildpack overhead

Cloud Foundry's default 60-second timeout would kill the app before it finishes starting.

Solution

Add manifest.yml to the fixtures/multibuildpack/rails72/ directory:

---
applications:
- memory: 1G
  timeout: 180
  health-check-type: port

Key Settings

  • timeout: 180: Allows 3 minutes for app to start (vs default 60s)
  • health-check-type: port: CF waits for app to bind its port (default, explicit here)
  • memory: 1G: Explicit memory allocation for the heavy Rails app
  • NO name attribute: Switchblade provides name via -n flag

How Switchblade Uses This

Verified in the switchblade source code:

// vendor/github.com/cloudfoundry/switchblade/internal/cloudfoundry/setup.go:346-348
_, err = os.Stat(filepath.Join(source, "manifest.yml"))
if err == nil {
    args = append(args, "-f", filepath.Join(source, "manifest.yml"))
}

Switchblade automatically uses manifest.yml if present when running cf push.

Timeline

Build Status Issue
#18 ✅ Succeeded Before timeout issues
#19-22 ❌ Failed Insufficient timeouts
#23 ❌ Failed Only test timeout fixed (PR #1178)
#24 🔴 Errored Docker Hub infrastructure issue
#25 ❌ Failed Manifest variable substitution error

Why This Wasn't Caught Before

Build #18 (Oct 2-3, last success) likely succeeded due to:

  • Better CF platform performance on that day
  • More available Diego cell resources
  • Faster app boot time on that specific run

What changed around Oct 3 (between builds #18 and #19):

  • bosh-deployment: 0fa63999 → 9a789787
  • cf-deployment-concourse-tasks: f5a26a00 → 6e5a4bfb

These infrastructure updates may have changed Diego cell performance or timeout behaviors.

Precedent

Similar approaches in this codebase:

Heavy apps consistently need more time across the board.

Testing

This fix:

  • ✅ Resolves manifest variable substitution error
  • ✅ Targets the actual root cause (CF app start timeout)
  • ✅ Works together with PR Fix multibuildpack integration test timeouts (builds #19-22 failures) #1178 (test timeout fix)
  • ✅ Only affects the rails72 multibuildpack fixture
  • ✅ No changes to test code required
  • ✅ No impact on other test fixtures
  • ✅ Low risk - standard CF manifest pattern

Expected Outcome

After this PR:

  1. Rails72 app staging completes (4-5 min) ✅ Already working
  2. cf push succeeds without variable errors ✅ Fixed by this PR
  3. cf start waits up to 180s for app boot ✅ Fixed by this PR
  4. App successfully starts and binds port ✅ Should succeed now
  5. Test Eventually checks pass (90s available) ✅ PR Fix multibuildpack integration test timeouts (builds #19-22 failures) #1178
  6. Test succeeds ✅✅✅

Verification

To verify this fix works:

  1. Check that next build uses this commit
  2. Monitor for absence of "Expected to find variables: name" error
  3. Monitor cf start command in logs - should succeed instead of timing out
  4. Test should reach the Eventually checks (not fail during deployment)
  5. Overall test should pass

Related

Fixes continued failures in build #23 where the nodejs multibuildpack
test still fails with "failed to start: exit status 1" even after the
Eventually timeout fix from PR #1178 was merged.

## Problem

The test failure in build #23 shows that the timeout fix from PR #1178
only addresses the test's Eventually timeout, but does NOT fix the
underlying issue: the CF platform itself times out when starting the app.

The error "failed to start: exit status 1" comes from switchblade's
internal/cloudfoundry/stage.go when the `cf start` command fails.

### Root Cause

Cloud Foundry has a **default 60-second timeout** for app starts. The
Rails 7.2 + Webpacker multi-buildpack fixture:
1. Staging takes 4-5 minutes (already completed successfully)
2. **App boot time exceeds 60 seconds** (Rails + Webpacker initialization)
3. CF kills the app before it finishes booting
4. `cf start` returns exit status 1
5. Test fails before even reaching the Eventually checks

## Solution

Add a `manifest.yml` to the rails72 test fixture with:
- `timeout: 180` - Allows 3 minutes for app to start (vs default 60s)
- `health-check-type: port` - CF checks if port is bound (default behavior)
- `memory: 1G` - Explicit memory allocation

Switchblade automatically uses manifest.yml if present (verified in
vendor/github.com/cloudfoundry/switchblade/internal/cloudfoundry/setup.go:346-348).

## Why This Wasn't Caught Before

Build #18 (last successful) likely succeeded due to:
- Better CF platform performance that day
- Lucky timing with Diego cell resources
- Faster app boot on that specific run

Builds #19-23 consistently fail because the infrastructure state changed
around Oct 3 (bosh-deployment and cf-deployment-concourse-tasks updates
observed between builds #18 and #19).

## Testing

This change:
- ✅ Allows Rails + Webpacker apps adequate time to boot
- ✅ Works with the timeout fix from PR #1178
- ✅ Matches the pattern from other heavy fixtures (JRuby has similar considerations)
- ✅ No impact on other tests (manifest only affects this fixture)

## References

- Build #23: Still failing after PR #1178 merged
- CF docs: Default app start timeout is 60 seconds
- Switchblade code: Automatically reads manifest.yml if present
- Related: PR #1178 (Eventually timeout fix - necessary but not sufficient)
@tnikolova82
tnikolova82 merged commit 21e1b1d into master Oct 9, 2026
7 checks passed
@tnikolova82
tnikolova82 deleted the add-manifest-for-rails72-timeout branch October 9, 2026 17:07
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