-
Notifications
You must be signed in to change notification settings - Fork 651
Fixed issue with Dynamic Repostitories not working #874
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
Fixed issue with Dynamic Repostitories not working #874
Conversation
@rubenmamo Thanks for this! But can you please rebase on |
@asbjornu I'm a bit new to git. I think I rebased it correctly. Let me know if it is not. |
@rubenmamo Thanks for trying, but this didn't end up quite right. 😃 Please try the following: git checkout ResolveDynamicRepositoryIssue
git branch ResolveDynamicRepositoryIssue-Backup
git reset --hard upstream/master
git cherry-pick e8fd5697e68436ac3a4b8a1e58dfbfa26deb687c This will first backup your current git remote add upstream https://github.com/GitTools/GitVersion.git When all of this is done, git push --force origin ResolveDynamicRepositoryIssue Please let me know if there's any problems or questions. Good luck! 👍 |
@asbjornu Followed your instructions and it seems to have worked Thanks a lot for your help |
@rubenmamo Yes, that looks perfect! Now if only @gep13 or @JakeGinnivan could weigh in on the implications of always doing |
@rubenmamo @asbjornu in all honesty, I am not going to have any chance to look at this in the immediate future :-( |
I looked at trying to implement a test for this, however I couldn't see a way of testing for this without re-engineering the whole method (which could probably cause more problems) Below is an excerpt of the method I modified.
Since the instance of GitPreparer is created inside the method I would not be able to mock it's execution (unless I'm missing something I'm unaware of) Unfortunately this specific bug makes GitVersion completely unusable with TeamCity when using Dynamic Repositories. I had to revert to GitVersion v3.3.0 in order to get my builds working, however v3.3.0 has another bug which causes GitVersion to not load the GitVersion.yml file from the repository (it tries to load it from the GitVersion folder) and hence I could still not work with v3.3.0. In the end I made this fix and copied a locally built GitVersion to my CI environment so that I could work. I suspect there might be other people who could run into this issue |
I suspect the bug was created in commit 9b336cd This change introduced the code in question in the ExecuteGitVersion method. In the previous commit ( 6d01254 ) of the file, GitPreparer was initialised in ExecuteInternal and the following code was present:
Notice the Initialise before the gitPrepare.GetDotGitDirectory() call I noticed that the current version of ExecuteInternal calls
Unfortunately this is not valid as gitPreparer.IsDynamicGitRepository is only setup after the call to gitPreparer.Initialise. I suggest that I change my Initialise code and the code in ExecuteInternal to be as follows:
any thoughts? |
@rubenmamo Nice find! Yes, I think that |
Thanks for investigating this @rubenmamo!
Happy to merge but did you want to give writing a test a go? If there are specific road blocks also let me know, we might be able to nut them out. |
I'll try writing a test for this. I think it's a bit more complex than just building a git repo on the fly though. Since this is related to Dynamic Repositories I need a fake project on disk without a .git folder, then ExecuteCore needs to somehow clone a repository and use it with the dynamic folders functionality. ExecuteCore will need the URL of a repository, I guess I could use the gitversion repository URL. |
Removed redundant call to gitPreparer.Initialise since it's now called earlier
I submitted an additional commit with the following changes:
I think this should cover everything we discussed. The tests pass on my machine. I just noticed the Travis CI build failed. I'm not sure why it's failed on Travis CI :( |
The log from the run of my machine is:
whilst the one from TravisCI is
The difference between my run and the one on TravisCI is that I ran the test against my own Git Repository since we have a proxy server at the office and it complicates life with running git version behind it. I suspect the issue might be related to permissions or access to the git repo from the server. Any thoughts? |
I have fixed the issue with the test. Basically I had copied the call to execute core from the other tests and used the same directory as the other tests (i.e. Environment.SystemDirectory). It seems that this property is set to empty string in TravisCI whilst it is needed to be filled with something in order for the process to proceed. I changed the test call to include a fake directory and the process worked. In order to understand what was happening on TravisCI I had to add some additional logging, see commits 335bf47 and 76d0535. Do you want me to revert these changes to the logs or are you happy keeping them in? |
|
||
RepositoryScope(versionAndBranchFinder, (fixture, vv) => | ||
{ | ||
versionAndBranchFinder.ExecuteGitVersion("https://github.com/GitTools/GitVersion.git", null, new Authentication(), "refs/head/master", false, "tempProjectPath", null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you look at the other tests in this file, fixture.RepositoryPath
is what's used. Environment.SystemDirectory
is used in the one test above just because it's guaranteed to:
- Exist.
- Not contain a
.git
folder.
@rubenmamo Great work on the test! I also think the logging is fine. I do have one comment regarding the path, though, so please just fix that for consistency and we should be good to go! 👍 |
I changed the path as discussed |
@rubenmamo Excellent! 👍 |
Merged in 66bc2b0. |
Fixed issue which was causing dynamic repositories to fail as per issue #782
Added missing call to gitPreparer.Initialise
Tested on my CI environment and it is working