PreviewHQ
  • Introduction
  • Basics
    • What is Continuous Product Review?
    • What is a Preview Environment?
    • Use Cases
      • Product and Stakeholder Review
      • QA Environments
      • Automated End-to-End Testing
      • Sales Demo Environments
      • Support Training
  • Getting Started
    • Installation
    • Add Configuration
    • Add a Cluster
    • Create a Deployment
      • with a Pull Request
      • with the Dashboard
      • with the CLI
      • with the API
  • Technical Stuff
    • Defining Deployments
      • Helm Charts
      • Kubernetes Manifests
      • [UNRELEASED] Terraform
    • Configuration File
      • Branches
      • Services
      • Chart Repositories
      • Chart Values
      • Docker Registries
      • Images
      • Webhooks
    • Template Strings
    • Using Seed Data
      • Using Shared Data Sources
    • Access Control
      • Preview Application Access
      • Preview Environment Access
    • Using Third-Party Integrations
    • Debugging
    • Current Limitations
  • Sample Applications
    • Emojivoto
    • Guestbook - Helm
    • Guestbook - Manifests
  • misc
    • FAQ
    • Changelog
    • Telemetry Data
    • Links
      • Homepace
      • Dashboard
Powered by GitBook
On this page
  • My app doesn't use HTTPS and it doesn't work. What gives?
  • My deployment failed, how can I see what went wrong?
  • My deployment has pending pods, why won't they schedule?

Was this helpful?

  1. Technical Stuff

Debugging

My app doesn't use HTTPS and it doesn't work. What gives?

By default, Preview hosted deployment clusters run under the envs.dev domain. Every .dev domain is on the HSTS preload list, which makes HTTPS required on all connections. Options to correct this are:

  1. Recommended: Enable HTTPS on your application. This is as simple as adding the kubernetes.io/tls-acme: "true" annotation on your Chart's Ingress.

  2. Use a non-Preview cluster with a custom hostname. This will allow you to use a domain which is not on the HSTS preload list.

My deployment failed, how can I see what went wrong?

We recognize this is a problem, and are looking to get a better feedback loop here. Part of the issue here is that we attempt to clean up failed deployments, which can make debugging difficult.

In your config file, you can set deploy.atomic: false, which will prevent automatic clean up of failed deployments. Note that this can leave deployments in a state that requires manual intervention in order to deploy again, so we do not recommend using this setting when not actively debugging.

deploy:
    atomic: false

If you are having difficulty debugging deployments, reach out and we'll jump on helping you figure out what went wrong.

My deployment has pending pods, why won't they schedule?

Preview environments have resource limits in place. These limits may prevent a pod from scheduling it if exceeds them. At the moment these limits can not be customized, but please let us know if you are hitting them.

PreviousUsing Third-Party IntegrationsNextCurrent Limitations

Last updated 4 years ago

Was this helpful?