For running .cdbrelease.lua, do a checkout first
(to include all files) and then write the export over
it (to apply substitutions).
The mod scan is still done on the export only,
to avoid including excluded paths.
- Automatically load detail edits from meta JSON, allowing release
of new descriptions to sync with release of package versions.
- Load long description from external markdown file.
- Automatically calculate provides/depends info if needed.
If --fromgit=<url> is specified:
- Shallow-clone the repo.
- Export the tree from the clone.
- Run .cdbrelease.lua hook in the root of the tree.
- Merge any data returned into config.
.cdbrelease.lua can do more-or-less whatever lua allows (e.g.
using dofile, filesystem access, etc.) to figure out the settings
it wants to provide. This allows it to do things like include
files from mods for shared versioning logic and perform more
complex version number calculations, like NodeCore does. It could
also be a security risk, so this should be used only on repos that
the user has good control over.
The canonical example is for .cdbrelease.lua to compute its own
version number from stats that get baked into the file by the
export step based on .gitattributes. Things like defaulting the
pacakge name and author are possible too.
Settings that are already explicitly specified at an earlier step
are ignored from .cdbrelease.lua.
