RFC: Provider Assets

[aleksrutins]

It would be useful to have some standard way for providers to have assets. For instance, the PHP provider has an Nginx configuration template and a Perl script to transform that template that it needs to have available in the container at runtime.

Maybe have an API like this:

app.add_asset("laravel.conf", include_str!("php/laravel.conf"));
app.add_asset("transform-config.pl", include_str!("php/transform-config.pl"), 0755); // with optional mode argument

// ...

let cfg_path = app.asset_path("laravel.conf");
let transform_path = app.asset_path("transform-config.pl");

This might be able to be implemented with tmpfiles or something.

I'd be happy to work on this at the same time as the PHP provider.

[ghost]

Yup, Even Staticfile provider requires nginx.conf. Maybe we can store these assets in a bucket and load them using Docker's ADD instruction.

[coffee-cup]

Instead of a bucket I think we should keep the files local to the provider and loaded into nixpacks at compile time.

[coffee-cup]

This is a good idea. As mentioned by wyzlle, a few other providers will need static assets as well.

One tricky thing about adding static assets to the build will be keeping build reproducibility in the build plan. The providers do not and should not have access to modify the app source directly. Instead, the providers are used to generate a build plan and the build plan is used to generate an image. This process allows the build plan to be saved and reused at a later date.

I think static assets can be implemented with an optional provider lifecycle method, similar to how environment variables work now. The provider

// Mapping from filename to content
pub type StaticAssets = HashMap<String, String>;

pub trait Provider {
    // ...

    fn environment_variables(
        &self, _app: &App, _env: &Environment,
    ) -> Result<Option<EnvironmentVariables>> {
        Ok(None)
    }

  fn static_assets(&self, _app: &App, _env: &Environment) -> Result<Option<StaticAssets>> {
    Ok(None)
  }
}

The build plan can then store these files in a JSON format. One downside is that the build plan size will increase quite a bit if the assets are large.

Open to other ideas as well. This was just a quick thought. The main thing to keep in mind though is that generating the build plan and using the build plan are two separate steps and can be run completly independently of each other.

[aleksrutins]

I wasn't talking about storing them directly in the project tree; I was thinking about storing them separately, maybe in /nixpacks/assets or as tmpfiles or something.

[aleksrutins]

Implemented in #159