Proposal: per startup project .s2i folder?

[tmds]

.NET repos tend to be organized with multiple folders split for application code, library code, tests, etc.

For this reason our builder has a DOTNET_STARTUP_PROJECT envvar that allows you to point it to the project you are actually going to build and run. This is more versatile than the s2i context-dir because it allows you to consume library code that is outside the application project, or run a number of test projects which are also in their own folder.

s2i has a .s2i folder which allows to set variables, and override scripts under using files under .s2i/bin.

This folder resides at the repository root (more specifically context-dir). This means if your project has multiple applications, they are all using the same files. This is constraining when you organize your code in a monolithic repository (opinionated) that contains multiple applications.

If it makes sense, we could allow users to have an .s2i folder under DOTNET_STARTUP_PROJECT which gets used by our s2i builder.

For example, we can pick up an environment file at DOTNET_STARTUP_PROJECT/.s2i/environment and source it in bash.

@bparees @adambkaplan @aslicerh @omajid @jnordell @DonSchenck if you have some thoughts on this, I'd love to hear them.

[adambkaplan]

This convention makes sense to me, and it feels like there is a lot developers can do here.

For example, if a project wants to override the assemble script, you could use have the image's root s2i assemble script delegate to a user-provided script in the project.

Example:

# .NET image .s2i/assemble

if [[ -f "${DOTNET_STARTUP_PROJECT}/.s2i/assemble" ]]; then
    source "${DOTNET_STARTUP_PROJECT}/.s2i/assemble"
fi

[tmds]

No plans to do this.