Add :tar option for releases to create a tarball

[Gazler]

Closes #9289

There are a couple of points worth discussing.

@ericmj mentioned using :systools, even if we want to change that, the tests, docs and validations in this PR should still be valid.

Currently the step is simply called :tar. Not sure if we want to use a different name, or allow users to build the tar in a different location (something like {:tar, "some/path/for/myapp.tar.gz"}

[tsloughter]

You need to use systools:make_tar or duplicate its functionality because simply including lib in the tarball will include the libs used by other versions of the release that may have been built.

[josevalim]

Not sure if we want to use a different name, or allow users to build the tar in a different location (something like {:tar, "some/path/for/myapp.tar.gz"}

i wouldn't worry about it for now, we can always add it later.

@Gazler can you look into using sys_tools? If that works, we don't need the :clean step.

[tsloughter]

You probably will need to copy the start.boot and such back to relname.boot before calling make_tar. It expects the release name to be the name of those files and mix currently renames them.

[josevalim]

Does it copy only the relname.boot file though? Because we have more than one... then it may be best to not use sys_tools and add a clean up task.

[Gazler]

Can we walk the runtime dependencies of each application in the struct and only include those directories from within the lib dir?

[tsloughter]

@josevalim yea, it copies that file into the archive as start.boot https://github.com/erlang/otp/blob/master/lib/sasl/src/systools_make.erl#L1770

@Gazler you can, that is what systools does.

[Gazler]

Thanks @tsloughter.

@josevalim What do you suggest? Should we go the systools route? Or are Elixir releases different enough that it'd be valuable to do it outside of systools?

[tsloughter]

Patching systools to allow copying the start.boot would be nice too :). You'd still need the hack to copy back to relname.boot when run on earlier OTPs but it would be a nice change.

[josevalim]

I am not confident systools would copy everything we need:

1. We have two .boot files
2. We have a releases/COOKIE file

So I am afraid we may need to perform a bunch of workarounds and rolling our own should be less lines of code (as we already have all applications and their versions listed in the release struct anyway.

[Gazler]

I've pushed the code that limits the directories added for lib and releases as a separate commit so you can see the diff more clearly.

[josevalim]

By using the path I proposed above, we don't need the rename anymore, but we will need to call File.rm before :erl_tar.create.

[tsloughter]

@josevalim relx uses make_tarto make the initial tarball, unpacks it and then copies in stuff it also needs (like overlays that allow you to include any file in a release).

Another thing that would be nice to have added to systools itself :)

[tsloughter]

Something I expect will come up is it doesn't look like you can include other files in the release. It is often useful for the user to be able to bundle any files they want along with the release.

[josevalim]

@tsloughter agreed. Any suggestions? Should we always include everything else at the root? Or should we allow them to list extra directories?

[josevalim]

In any case, I would merge this as is and add extra directories support next.

[ericmj]

Thank you @Gazler! 💜

[tsloughter]

@josevalim I suggest requiring an explicit list of additional files/directories to include. Otherwise you risk including shit like logs if they ran the release from the _build dir at some point before tar'ing.