fix(buildpack): use Procfile when BUILDPACK_URL is set

[duanhongyi]

Builder uses dockerfile by default when Procfile and Dockerfile coexist, even if BUILDPACK_URL has been set.
I don't think that's reasonable, because the user sets the BUILDPACK_URL to indicate that the user wants to use the buildpack.

[Cryptophobia]

I would like to let other people discuss this as well @kingdonb @tolstenko @felixbuenemann @till @rwos .

In my past experience, it has been nice to default to Dockerfile build if the Dockerfile is present in the repository.

builder/pkg/gitreceive/build_type.go

Line 20 in 6668920

_, err := os.Stat(fmt.Sprintf("%s/Dockerfile", dirName))

I'm always hesitant to change the default behavior as this will create noise and we would need documentation and annoucements to make users aware.

[till]

Yeah, that's an odd default behaviour. I can see where @duanhongyi is coming from.

I haven't looked at the rest of the code in too much detail, does it tell the user "somewhere" what is being used?

[Cryptophobia]

@till @duanhongyi The only way I know to check at the moment is to hit the controller api and get the latest build for an app. That will tell you if procfile or dockerfile struct is set on the build of an app:

https://docs.teamhephy.com/reference-guide/controller-api/v2.3/#builds

[felixbuenemann]

I think this makes sense, as long as BUILDPACK_URL is explicitly set, the Dockerfile might be simply for local development or builds.

[till]

The more I think about it, the more I see this as uncertain behaviour right now. Why set a build pack and then expect the Dockerfile to be used. Def. sounds like a BC break as it may be what happens for people right now, but I think it's also more explicit going forward.

[duanhongyi]

Or we let users set BUILD_TYPE themselves, and when dockerfile and procfile exist at the same time, we use BUILD_TYPE environment variables to decide.

[Cryptophobia]

Or we let users set BUILD_TYPE themselves, and when dockerfile and procfile exist at the same time, we use BUILD_TYPE environment variables to decide.

This solution sounds nice as well but might require a bit more code. What does everyone else think?

[felixbuenemann]

I think it would make sense to implement 'heroku stack:set' in hephy workflow. Using 'deis stack:set container' would be used for Dockerfile and Dockerimage, while different heroku stacks could be used for slugrunner.

I ran into trouble when upgrading from Deis Workflow to Hephy Workflow, because the Heroku Stack was switched from Cedar-14 to Heroku-18, which does not support ruby 2.3, so lots of apps could no longer deployed and had to be upgraded to ruby 2.4 which has quite a bit of breaking changes.

It would have been much easier to just be able to set those apps to the old stack.

See: https://devcenter.heroku.com/articles/stack

[duanhongyi]

@felixbuenemann I agree with you very much, but there may be a lot of changes to be made in this way.

[felixbuenemann]

@duanhongyi It‘s certainly more involved. I think your proposed fix will be useful in the meantime.

[felixbuenemann]

@duanhongyi It would be nice, if you could add a test to pkg/gitreceive/build_test.go to document the expected behaviour.

@Cryptophobia I think test coverage would be great, otherwise I vote for merging this fix.

[kingdonb]

This seems like a great idea, make it really easy to switch back to buildpacks. I usually have tested switching from Procfile to Dockerfile and that process is smooth enough, but other than nuking the Dockerfile I'm not sure how I'd switch builds back to using buildpacks right now. "Add a BUILDPACK_URL" seems like a really obvious solution and easy to document.

[Cryptophobia]

Going to merge this in now that we have agreed that it is the best short-term fix solution going forward. Ideally, we would like to implement something like heroku stacks per @felixbuenemann recommendation but that would require the builder to use different base images and a bit more work.

[Cryptophobia]

lgtm!