Skip to content

Fixed issues #863 and #870: invalid cache key computation and config file location #892

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

Closed
wants to merge 21 commits into from

Conversation

sergiorykov
Copy link
Contributor

ConfigurationProvider verifies consistency of config files (project root and working directories) before executing commands.
Cache key computation uses ConfigurationProvider to get valid config file path.

Appropriate tests are included.
#863 #870

@sergiorykov
Copy link
Contributor Author

@asbjornu Can you take a look? It seems pull request is going to be outdated because of other pull requests are being merged.

@@ -108,6 +110,11 @@ static int VerifyArgumentsAndRun()
return 0;
}

private static void VerifyConfiguration(Arguments arguments, IFileSystem fileSystem)
{
var gitPreparer = new GitPreparer(arguments.TargetUrl, arguments.DynamicRepositoryLocation,arguments.Authentication,arguments.NoFetch,arguments.TargetPath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick, but can you please format this according to the ReSharper style settings? We at least want spaces after commas, but if the line is very long, it would be nice with line breaks after each argument and the arguments aligned.

@asbjornu
Copy link
Member

@sergiorykov I think this looks good! Thanks for taking the time to look into this and fixing it. I have a couple of in-code comments and also wonder if this is now tested well enough. Do you think it's possible to create a few tests verifying the different cache invalidation scenarios, so this don't regress in the future?

@sergiorykov
Copy link
Contributor Author

Checked caching key calculation.

I've done a bit more - by process it's not good tone :(.

Calculating cache key depends on three things: git metadata, config file, /overrideconfig from command line.

git metadata changes for cache key calculation requires a bit more abstractions and I think it's not nessesary to add regression tests for it.

config file changes test requires configuring abstraction of git with two different tag-prefixes.
default config file will have first tag-prefix and version will be returned according to it. Then we will update config with second tag-prefix and should receive other version. (It was my case)
If you will say how to configure that context I will add tests in separate pull request.

overrides from command line - that case was ignored at all. I've added support for it with a test.


WarningException exception = Should.Throw<WarningException>(() => { ConfigurationProvider.Verify(workingPath, repoPath, fileSystem); });

var expecedMessage = string.Format("Ambigous config file selection from '{0}' and '{1}'", workingDirectoryConfigFilePath, repositoryConfigFilePath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: It's "ambiguous". 😃

@asbjornu
Copy link
Member

@sergiorykov Thanks again! I've made a few more comments inline. Please go over them and let me know what you think.

…Branches

Will be eventually corrupted back after applying Resharper's clean code.
Will need to do smth with it.
@sergiorykov
Copy link
Contributor Author

Thank for your help and detailed code review!

@@ -4,6 +4,8 @@ GitVersion 3.0 is mainly powered by configuration and no longer has branching st
## Configuration tool
If you run `GitVersion init` you will be launched into a configuration tool, it can help you configure GitVersion the way you want it.

It will create file 'GitVersion.yml' in directory where you launched initialization. It can be root repository directory or any subdirectory in case when you have single repository for more then one project or restricted to commit into subdirectory.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this reads a bit better?

Once complete, the init command will create a GitVersion.yml file in the working directory. It can be the root repository directory or any subdirectory in case you have a single repository for more than one project or are restricted to commit into a subdirectory.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accepted 96e41c7 :)

@asbjornu
Copy link
Member

@sergiorykov I've replied and see that you need to do a rebase before this can be merged. 😃

@JakeGinnivan
Copy link
Contributor

I can merge manually if you are busy @sergiorykov, is there anything outstanding to do on this PR?

@sergiorykov
Copy link
Contributor Author

I'm really sorry - that time was purely devoted to work.

I will add corrections in a day or two and it will be ready to merge.

@sergiorykov
Copy link
Contributor Author

It seems all comments are considered.

It's still hard to unit test cache key calculation, but it became clear what components are being used:

public class GitVersionCacheKeyFactory
{
        public static GitVersionCacheKey Create(IFileSystem fileSystem, GitPreparer gitPreparer, Config overrideConfig)
        {
            var gitSystemHash = GetGitSystemHash(gitPreparer, fileSystem);
            var configFileHash = GetConfigFileHash(fileSystem, gitPreparer);
            var repositorySnapshotHash = GetRepositorySnapshotHash(gitPreparer);
            var overrideConfigHash = GetOverrideConfigHash(overrideConfig);

            var compositeHash = GetHash(gitSystemHash, configFileHash, repositorySnapshotHash, overrideConfigHash);
            return new GitVersionCacheKey(compositeHash);
        }

@JakeGinnivan
Copy link
Contributor

@sergiorykov if you are still around could you rebase this branch? Would love to release in 3.6.1 Then get 4.0.0 out after

@JakeGinnivan
Copy link
Contributor

If you don't have time also let me know and ill do it :)

I will do it either way this arvo.

@JakeGinnivan JakeGinnivan mentioned this pull request Jul 17, 2016
@JakeGinnivan
Copy link
Contributor

Merged via #951

@sergiorykov
Copy link
Contributor Author

Thanks!

Different timezones. ^)

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