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

Allow to use paths relative to flyway.conf location #944

Closed
alexei-osipov opened this issue Jan 28, 2015 · 14 comments
Closed

Allow to use paths relative to flyway.conf location #944

alexei-osipov opened this issue Jan 28, 2015 · 14 comments

Comments

@alexei-osipov
Copy link

@alexei-osipov alexei-osipov commented Jan 28, 2015

Right now locations defined in flyway.properties are relative to current working directory. This may be a command line tool location or location of pom.xml for Maven plug-in. This makes it very difficult to use single flyway.properties to run some set of migrations.

Example file structure:
/someproject/migrations/flyway.properties
/someproject/migrations/sql/V1__aaa.sql
/someproject/migrations/sql/V2__bbb.sql
/someproject/pom.mxl
/tools/flyway/flyway.cmd

Right now if I want to run migrations from maven plug-in with option configFile I have to set flyway.locations to migrations/sql in it. If I want to use same flyway.properties from command line tool I have to explicitly override locations with absolute path to sql file folder.

So I suggest to add a boolean option locationsAreRelativeToConfig. If it set to true then location of flyway.properties (or another file provided by configFile option) should be used as base directory for locations. So for example above it will be possible to set
flyway.locations=filesystem:sql
and use flyway.properties file both from maven plug-in and command line tool.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Jan 28, 2015

Thanks for the suggestion. I am not a fan of adding a config property for this. However... This behavior is currently unspecified. We could therefore specify it to be relative to either the current directory or, like you suggest, the directory the config was loaded from.

I'll need to put some thought into this as the what the implications are exactly.

In your case you can of course also simply put the location need for the command-line tool in the config file and override with the plugin config in the pom. All other proper can stay as is.

@punkstarman
Copy link

@punkstarman punkstarman commented Mar 9, 2015

I think that execution from the command line should resolve non-classpath relative paths by using the working directory (not the install directory), and the build tool should use the project root.
I believe that this behaviour is in line with most command line and build tools.
The change would only affect the wrapper scripts.

@punkstarman
Copy link

@punkstarman punkstarman commented Mar 9, 2015

I have successfully used the following wrapper scripts:

Unix

cygwin=false
case "`uname`" in
  CYGWIN*) cygwin=true;;
esac

# resolve links - $0 may be a softlink
PRG="$0"

while [ -h "$PRG" ] ; do
  ls=`ls -ld "$PRG"`
  link=`expr "$ls" : '.*-> \(.*\)$'`
  if expr "$link" : '/.*' > /dev/null; then
    PRG="$link"
  else
    PRG=`dirname "$PRG"`/"$link"
  fi
done

# Set the current directory to the installation directory
INSTALLDIR=`dirname "$PRG"`

# Use JAVA_HOME if it is set
if [ -z "$JAVA_HOME" ]; then
 JAVA_CMD=java
else
 JAVA_CMD=$JAVA_HOME/bin/java
fi

CP="$INSTALLDIR/lib/*:$INSTALLDIR/drivers/*"

if $cygwin; then
  CP=$(cygpath -pw "$CP")
fi

"$JAVA_CMD" -cp "$CP" org.flywaydb.commandline.Main $@

# Save the exit code
JAVA_EXIT_CODE=$?

# Exit using the same code returned from Java
exit $JAVA_EXIT_CODE

Windows

@Echo off

setlocal

@REM Use JAVA_HOME if it is set
if "%JAVA_HOME%"=="" (
 set JAVA_CMD=java
) else (
 set JAVA_CMD="%JAVA_HOME%\bin\java.exe"
)

%JAVA_CMD% -cp "%~dp0\lib\*;%~dp0\drivers\*" org.flywaydb.commandline.Main %*

@REM Save the exit code
set JAVA_EXIT_CODE=%ERRORLEVEL%

@REM Exit using the same code returned from Java
EXIT /B %JAVA_EXIT_CODE%
@RichardJECooke
Copy link

@RichardJECooke RichardJECooke commented Dec 29, 2015

+1 for relative paths. First thing I'm Googling as a brand new user.

@hotzen
Copy link

@hotzen hotzen commented May 10, 2016

+1 as well

@zetzet
Copy link

@zetzet zetzet commented Jun 15, 2016

++: relative paths would be super helpful

@jedvardsson
Copy link

@jedvardsson jedvardsson commented Jun 22, 2016

Yes, I agree that it would be helpful to have some way to make references relative to the configuration file itself. I suggest looking at e.g. TypeScript and how it uses ./to denote that the referenced module is located relative to the referencing file. Thus file:myconfigs can still mean relative to the working dir and file:./myconfigs can mean relative to the config file.

Alternately, we could use a variables like $workdir and $confdir to be even more explicit.

@axelfontaine axelfontaine added this to the Flyway 4.1 milestone Jun 22, 2016
@miro-ur
Copy link

@miro-ur miro-ur commented Oct 4, 2016

+1, relative paths would be super

@r0mdau
Copy link

@r0mdau r0mdau commented Jan 3, 2017

+1

@axelfontaine axelfontaine modified the milestones: Flyway 5.0, Flyway 4.1 Feb 7, 2017
@JDFagan
Copy link

@JDFagan JDFagan commented Mar 6, 2017

This also should apply to flyway.conf (not just flyway.properties) as well, I want to simply define this:

flyway.locations=./sql/

So that flyway can pickup my sql from Git repo in repo sub-directory where . represents current directory of my project root (i.e., my git repo directory).

--
Update:

My noob mistake. I got the above to work by changing above to:

flyway.locations=filesystem:./sql/

@axelfontaine axelfontaine changed the title Allow to use paths relative to flyway.properties location Allow to use paths relative to flyway.conf location Nov 27, 2017
axelfontaine added a commit to flyway/flywaydb.org that referenced this issue Nov 27, 2017
@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Nov 27, 2017

This has now been implemented for all client:

  • Command-line: relative to the current directory
  • Maven: relative to the pom.xml directory
  • Gradle: relative to the build.gradle directory
@lbreuss
Copy link

@lbreuss lbreuss commented Dec 21, 2017

Regarding the maven plugin, other plugins provide a workingDirectory parameter.

For my schema unit tests, I would really like to use the original bundled /src/main/resources/util/flyway/conf/flyway_latest.conf, that references filesystem:../../database/. Now if during test phase I direct flyway-maven-plugin to use the config file at /target/util/flyway/conf/flyway_latest.conf, the relative path does not evaluate to /target/database/, but to /../../database/, which is an inexistent path and even outside the maven project. Currently, as a workaround, I have to use a filtered version of flyway_latest.conf.

Sorry to bring this 944 up again. I would have loved that the original posters desired behaviour would become the default: relative to the conf file.

I think in any case it would still be a good idea to allow the plugin to explicitely change to a workingDirectory.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Dec 21, 2017

@lbreuss This is essentially a new feature request. Please file a new issue for that.

@lbreuss
Copy link

@lbreuss lbreuss commented Dec 21, 2017

Agree. #1877

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.