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

fix(buildpack): use Procfile when BUILDPACK_URL is set #49

Merged
merged 1 commit into from
Jul 28, 2019

Conversation

duanhongyi
Copy link
Member

@duanhongyi duanhongyi commented Apr 3, 2019

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.

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
Copy link
Member

Cryptophobia commented Apr 3, 2019

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.

_, 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.

Copy link

@till till left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

@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
Copy link
Contributor

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

@till
Copy link

till commented Apr 4, 2019

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Contributor

felixbuenemann commented Apr 7, 2019

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
Copy link
Member Author

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

@felixbuenemann
Copy link
Contributor

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

@felixbuenemann
Copy link
Contributor

@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
Copy link
Member

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
Copy link
Member

Cryptophobia commented Jul 28, 2019

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.

Copy link
Member

@Cryptophobia Cryptophobia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@Cryptophobia Cryptophobia merged commit 1c98f09 into teamhephy:master Jul 28, 2019
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.

5 participants