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

Buildpack default launch type is no longer correct #6948

Closed
djcass44 opened this issue Dec 8, 2021 · 1 comment · Fixed by #6979
Closed

Buildpack default launch type is no longer correct #6948

djcass44 opened this issue Dec 8, 2021 · 1 comment · Fixed by #6979
Labels
area/build build/buildpacks kind/bug Something isn't working needs-reproduction needs reproduction from the maintainers to validate the issue is truly a skaffold bug priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence.

Comments

@djcass44
Copy link

djcass44 commented Dec 8, 2021

Expected behavior

Buildpacks will set the correct launch type.

Using a custom build method that directly calls the Pack CLI:

pack build "$IMAGE" \
	--builder paketobuildpacks/builder:tiny \
	--run-image paketobuildpacks/run:tiny-cnb
Setting default process type 'myapp'
Saving dev.local/myapp:2303623-dirty...
*** Images (1952faebeb1a):
      dev.local/myapp:2303623-dirty
Reusing cache layer 'paketo-buildpacks/go-dist:go'
Adding cache layer 'paketo-buildpacks/go-build:gocache'
Successfully built image 'dev.local/myapp:2303623-dirty'

As you can see it correctly sets the default process type to 'myapp' and the application starts up normally.

Actual behavior

Buildpacks use the web launch type which is no longer set as of Platform API 0.6.

[exporter] Warning: default process type 'web' not present in list [myapp]
[exporter] Saving dev.local/myapp:latest...
[exporter] *** Images (5b1a84af1b52):
[exporter]       dev.local/myapp:latest
[exporter] Reusing cache layer 'paketo-buildpacks/go-dist:go'
[exporter] Adding cache layer 'paketo-buildpacks/go-build:gocache'

Using the Skaffold buildpacks config (shown in full below), Skaffold incorrectly sets the default process type to web which is no longer valid. This causes the application to start with error and requires manually overriding the ENTRYPOINT.

Information

  • Skaffold version: v1.35.0
  • Operating system: Amazon Linux 2
  • Installed via: GitHub Releases
  • Contents of skaffold.yaml:
apiVersion: skaffold/v2beta26
kind: Config
metadata:
  name: foobar
build:
  artifacts:
    - image: dev.local/myapp
      buildpacks:
        builder: paketobuildpacks/builder:tiny
        runImage: paketobuildpacks/run:tiny-cnb
  local:
    push: false

Steps to reproduce the behavior

  1. Create a simple Go app
  2. Add the above skaffold.yaml
  3. skaffold build
  4. docker run or deploy the app (in my environment it's to Minikube) without modifying the entrypoint
  5. Notice the failed to launch: determine start command: when there is no default process a command is required error
jimmykarily pushed a commit to epinio/epinio that referenced this issue Dec 14, 2021
Something has changed on how the lifecycle binary works:

GoogleContainerTools/skaffold#6948

Probably this:

```
When using platform API 0.6 or greater, the lifecycle will assume that buildpacks on buildpack API less than 0.6 intended for web processes to be the default (#520 by @dwillist and @yaelharel)
```

from here: https://github.com/buildpacks/lifecycle/releases/tag/v0.11.0

Without the Procfile we get this warning during staging:

```
Warning: default process type 'web' not present in list [golang-sample-app]
```

and then the app fails to start with:

```
ERROR: failed to launch: determine start command: when there is no default process a command is required
```

Adding a Procfile with the "web" process fixes it.
@tejal29 tejal29 added area/build build/buildpacks needs-reproduction needs reproduction from the maintainers to validate the issue is truly a skaffold bug priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence. kind/bug Something isn't working labels Dec 14, 2021
@briandealwis
Copy link
Member

Skaffold is still linking with buildpacks/pack v0.18.1 due to buildpacks/pack#1245. It looks like that implements Platform API 0.4, whereas later versions of pack implements newer Platform API?

buildpacks/pack#1245, and updating Skaffold to link with buildpacks/pack v0.23.0 seems to do the right thing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build build/buildpacks kind/bug Something isn't working needs-reproduction needs reproduction from the maintainers to validate the issue is truly a skaffold bug priority/awaiting-more-evidence Lowest Priority. May be useful, but there is not yet enough supporting evidence.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants