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

Feature/flexible release package location on relups #505

Conversation

lrascao
Copy link
Collaborator

@lrascao lrascao commented Sep 5, 2016

Right now, when performing a relup using relx generate scripts, you need to take the tarball containing the relup of the next version and rename it to a specific filename (<relname>.tar.gz) which must be located in a specific location (releases/<version>), when you generate a tarball the filename contains the version number so this renaming is inconvenient, this PR allows for a more flexible way:
When running the unpack/install the upgrade install will search a set of locations and look for a tarball which meets the necessary criteria, it either contains the version number we're looking for or it conforms to the previous naming scheme for retro-compatibility, it then symlinks this tarball to one the release_handler is expecting (ie. releases/<version>/<relname>.tar.gz). The set of locations used to look for the user's tarball are (in order):
releases/<relname>-<version>.tar.gz
releases/<version>/<relname>-<version>.tar.gz
releases/<version>/<relname>.tar.gz

@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch 2 times, most recently from 986b386 to 9218f9a Compare September 26, 2016 16:59
@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch 2 times, most recently from 9e5e3d9 to 280cae4 Compare October 6, 2016 23:20
@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch 3 times, most recently from 50ca104 to 131cc28 Compare October 27, 2016 23:59
The second argument is actually the version and
not the package name.
@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch from 131cc28 to f4ea9d1 Compare October 28, 2016 11:39
@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch 2 times, most recently from de9d7ac to 053f491 Compare October 29, 2016 22:37
Instead of forcing the user to put the tarball package
with the expected name (<relname>.tar.gz)and in the
expected location (releases/<version>) symlink this
fixed file name to a tarball existing in one of three different
places (releases/, releases/<version>,
releases/<version>/<relname>.tar.gz).
Refactor the install/upgrade escript to make it more
dynamic, it now runs commands that are passed from
the start script while accepting a variable number
of arguments.
Add a `versions` command to the extended start
script that prints out the currently installed versions
and their status.
@lrascao lrascao force-pushed the feature/flexible_release_package_location_on_relups branch from 053f491 to a3bffca Compare October 29, 2016 22:43
@lrascao lrascao merged commit 55606fd into erlware:master Oct 29, 2016
@lrascao lrascao deleted the feature/flexible_release_package_location_on_relups branch October 29, 2016 23:08
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

Successfully merging this pull request may close these issues.

1 participant