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

Avoid reversing relx overlays. #1563

Merged
merged 1 commit into from
Jun 1, 2017
Merged

Avoid reversing relx overlays. #1563

merged 1 commit into from
Jun 1, 2017

Conversation

djnym
Copy link
Contributor

@djnym djnym commented Jun 1, 2017

This mostly moves a lists:reverse/1 which ensures that profile overlays
are run first but keeps the order of overlays otherwise.

This mostly moves a lists:reverse/1 which ensures that profile overlays
are run first but keeps the order of overlays otherwise.
@tsloughter
Copy link
Collaborator

Ah, this looks right, thanks!

@ferd ferd merged commit 5ab3230 into erlang:master Jun 1, 2017
@ferd
Copy link
Collaborator

ferd commented Jun 1, 2017

Nice, thanks for the fix!

@djnym djnym deleted the relx-overlay-fix branch June 1, 2017 20:39
ferd added a commit to ferd/rebar3 that referenced this pull request Aug 15, 2017
This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see erlang#1609)

This is done while adequately maintaining the order of operations that
were required as part of erlang#1563

Overlay vars of profiles are also checked to be taking the same profile
order, along with a test.

This fixes erlang#1247 and erlang#1609
ferd added a commit to ferd/rebar3 that referenced this pull request Aug 15, 2017
Specifically, this impacts profiles. It appears that relx as a whole
requires its configuration to be merged in one tuple order (New takes
precedence over Old), whereas the overlays require the opposite (Old
takes precedence over New) since the operation order on disk is
important to work well.

This patch reorders overlay values such that the overlay of a profile
takes place *after* the basic overlay, ensuring that the profile actions
take place after the basic ones; this allows profiles to properly
overwrite files as expected (see erlang#1609)

This is done while adequately maintaining the order of operations that
were required as part of erlang#1563

Overlay vars of profiles are also checked to be working fine, along with
a test.

This fixes erlang#1247 and erlang#1609
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.

3 participants