axion-release-plugin icon indicating copy to clipboard operation
axion-release-plugin copied to clipboard

pre commit hook does not commit files

Open jvtrigueros opened this issue 8 years ago • 6 comments

I'm not quite sure where the issue here lands, but I'm having an issue with the pre 'commit' hook. I have the following code:

...
String pluginPath = "src/main/resources/META-INF/plugin.xml"
    hooks {
        pre 'fileUpdate', [ file: pluginPath
                          , pattern: {v, c -> /(<version>)${c.readVersion()}/}
                          , replacement: {v, c -> "\$1$v"}
                          ]

        // fixes my issue
        pre { c ->
            c.logger.info("Adding $pluginPath to `patternsToCommit`")
            c.addCommitPattern(pluginPath)
            c.logger.info("$c.patternsToCommit")
        }

        pre 'commit'
    }
}
...

If I don't include the custom pre release hook and add the pluginPath string manually, that file wont get committed. I'm sure this is an issue with jgit and Windows paths.

This works because the way files are added to the patternsToCommit array is inconsistent. If file is added via the fileUpdate hook, the file's absolute path is resolved. Whereas, if this is done manually, then the string is added directly into the patternsToCommit array without first converting it into an absolute path.

I don't know what the correct solution here is, but it'd be nice if it were consistent. I, personally, would opt for the choice that works on Windows :smile: Is there a way to create a Linux looking path so that jgit doesn't freak out?

PS This is the repo I've been testing your plugin on. Good stuff!

jvtrigueros avatar Mar 07 '16 01:03 jvtrigueros

Hi :) Just to be clear - the problem is with fileUpdate hook resolving absolute path that does not work with JGit on Windows?

adamdubiel avatar Mar 07 '16 08:03 adamdubiel

Sorry, I should've gotten to the point sooner, just wanted to give a thorough description before posting. Yes, I suspect that JGit is crapping out when it is given a canonicalPath which is an absolute Windows path, in this case. I'm assuming the issue is only on Windows because all of the tests pertaining to this pass. I tried running the test myself locally, but they all failed. I could be doing something wrong, I've never written a Gradle plugin before.

jvtrigueros avatar Mar 07 '16 18:03 jvtrigueros

No, that might be env specific behavior. I don't have access to any Windows box, but i will try to dig into the literature about this and try to come up with some fix, hope you will be able to test it for me :)

adamdubiel avatar Mar 07 '16 21:03 adamdubiel

Most definitely! Anything I can do to help, if there's literature that you can point me to on how to get the tests running etc, I would be able to help out better. Right now I'm hitting an issue when created a Dummy Project using Gradle's API, but this should probably be a different issue :)

jvtrigueros avatar Mar 07 '16 21:03 jvtrigueros

I'm also not getting commits to work in Windows with this code:

pre 'fileUpdate', [files: ['src/main/java/project.production.properties', 'src/main/java/project.qa.properties', 'src/main/java/project.development.properties', 'src/test/java/project.test.properties'], pattern: {v, ctx -> /trackit_version=.*/}, replacement: {v, c -> "trackit_version=${v.replaceAll(/-SNAPSHOT$/, "")}"}]
pre 'commit', {v, p -> "Commit pre for version $v" }

ProTrent avatar Jan 17 '17 23:01 ProTrent

Using the same workaround mentioned by @jvtrigueros works for me for now:

pre { c ->
            c.addCommitPattern('src/main/java/project.production.properties')
            c.addCommitPattern('src/main/java/project.qa.properties')
            ....
        }

ProTrent avatar Jan 17 '17 23:01 ProTrent