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

Use Cross for docker builds #96

Open
loafofpiecrust opened this issue Jan 24, 2021 · 1 comment
Open

Use Cross for docker builds #96

loafofpiecrust opened this issue Jan 24, 2021 · 1 comment

Comments

@loafofpiecrust
Copy link

💡 Feature description

Your lambda-rust docker image seems to be about three major rust versions behind, so I can't use it anymore. I need features that went stable in 1.47.0. My solution was to use cross which seems to be the de-facto standard for cross compilation.

💻 Basic example

It's very easy to use. I got it working on a fork of this repo with a one line change to use "cross" instead of "cargo" for the "local build" setting.

To get it working with AWS Lambda, I also had to add this to my Cross.toml:

[target.x86_64-unknown-linux-musl]
image = "clux/muslrust:1.48.0"
@softprops
Copy link
Owner

Thanks for the suggestion. I’d be open to making this an opt in option.

Some context. The lambda execution environment is a very specific execution environment. In the beginning this was a harder lesson learned trying to come up with the right build env.

Fortunately a project is existed to solve this specific problem by proving a containerized replica of the precise lambda runtime as well as build time variants, the lambda ci project

The lambda rust docker container is an extension of that with a minimal rust tool chain installed and an set of assembly commands to create a package format lambda expects.

Combining the build and assembly components proved problematic as many users have unique build and assembly needs and the lambda rust container grew to accommodate them

Docker itself has proved to introduce its own set of problems with permissions of files and cross platform docker nuances. It also created something of a maintenance bottleneck for this plugin. Every time the docker image changed I had to publish a new version of this plugin which became onerous. Eventually I decided that since it was possible to pin an image version I made the default option use the latest docker image. Because rust pushes a new version every six weeks I also have a fixed maintenance if building a publishing that docker image every six weeks. This also became onerous.

Fast forward to today, after becoming more conscious of the problems docker introduced those began to outweighs the benefits of the problems it solved. I’m looking to lean more into entirely local builds documenting the few errors extra few extra dependencies required. Since those are few in number that frees up a majority of the maintenance burden as well as unblock users that have unique build dependency requirements. Those all can be installed on the host machine more easily that worked into the lambda docker image.

With all that context in mind I’m aiming to phase out the docker building support. Making cross a default would bring me back where I started, perhaps a step back as it reflects the lambda runtime less than the lambda ci images.

I would be open to making this an opt in alternative to local build option as I phase out the existing docker option.

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

No branches or pull requests

2 participants