-
Notifications
You must be signed in to change notification settings - Fork 651
NuGetUtils update #1645
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
NuGetUtils update #1645
Conversation
Looks like everywhere the same test is failing OutputsShouldMatchVariableProvider |
Not really, we need to check if there is any difference between these 2 branches |
3ef9634
to
3f525c4
Compare
@arturcic, I did a fresh |
Great! My question is why do we have 2 PRs? |
So I guess this PR will get merged instead of the other one |
Yes, this resolves #1634 so as soon this is merged, it will be closed automatically. It would be neat if GitHub supported |
3f525c4
to
37b2aa1
Compare
Sigh. Seems like my rebase failed for some reason. |
37b2aa1
to
99300d1
Compare
I'm going to assume that it's actually ok as is, since the logger.reset is actually paired with a setloggers call at the beginning of the function (rather than in a constructor as it was previously...) |
Thanks for the insight, @tpaxatb. Then I guess this just needs review and approval from @dazinator and we should be good to go. Do you agree, @arturcic? |
Agree |
@asbjornu Yes, that is indeed a mistake. Rebase ended up being a bit messy even though I followed instructions, sorry about that. I have close to zero experience with rebasing stuff, as I've never worked with GIT repo which follows SVN workflow. But yeah if @tpaxatb was ok with that, then it's fine. At least nothing should really interact directly with the MSBuild things anymore. The question is, does the NuGetUtils.MSBuild.Exec task factory handle logging using @dazinator Do I need to do any changes anywhere? The change request about the .csproj file seems to be not-relevant anymore, at least when looking at current state of https://github.com/asbjornu/GitVersion/blob/feature/NuGetUtilsUpdate/src/GitVersionTask/GitVersionTask.csproj . |
Hmm, actually, it seems I have some bug introduced in recent commits, despite the fact that I've added tests for the NuGetUtils.MSBuild.Exec. I'll investigate and back to you. |
Found the bug, it was only appearing in some quite special circumstances (e.g. having multiple assembly files in same package or having certain dependencies). I've fixed it now for |
99300d1
to
e6a6bec
Compare
any updates? |
Hey @feitzi , for my part, everything should be ok, I think. The NuGetUtils task factory has been tested and put into use by GitVersionTask. I am not sure what the conflicts mentioned here are exactly about - it seems that GitVersionTask is using workflow from SVN originally (based on some message I saw in this or another issue). |
…ory name in .props file.
…successfully now. Also modified the task factory parameter as needed.
…g with ITaskItems (seen as String arrays to GitVersionTask).
…e thorough check later though.
…down the amount of process invocations used by the task factory.
e6a6bec
to
1a09bc3
Compare
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.
I've rebased and resolved conflicts, but I was unable to figure out how to properly apply the changes made by @arturcic in 3e37390 to your complete rewrite of GenerateGitVersionInformation
, UpdateAssemblyInfo
and WriteVersionInfoToBuildLog
@stazz.
I now also noticed the change of GenerateGitVersionInformation
and GitVersionTaskBase
to static
, which feels very strange for the latter class especially. Having a Base
class that can't be inherited from doesn't make much sense, imho. Overall I believe what the PR does is good, I'm just unsure of the details in how it's implemented and now with the changes introduced in just about all classes this PR touches, I'm unsure of the validity of this PR as a whole.
Would it be too much to ask that you made a fresh attempt at implementing NuGetUtils without the major refactoring to static
and such you've done in this PR, @stazz? That would make it much easier to review and merge. In its current state, I'm not comfortable merging this at least.
|
||
public class GenerateGitVersionInformation : GitVersionTaskBase | ||
public static class GenerateGitVersionInformation |
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.
@stazz, why the change to static class
here?
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.
The reason is that the class has no state on its own anymore (instead, the Input
and Output
inner classes are used), so no instances of it will be created either.
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.
I see. Thanks for the explanation.
|
||
GitVersionInformationFilePath = Path.Combine(workingDirectory, fileName); | ||
public sealed class Input |
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.
@stazz, why isn't any form of inheritance used across the different Input
classes (and Output
classes, for that matter)?
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.
I simply forgot to do that. I'll fix this on Sunday.
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.
Great!
public bool NoFetch { get; set; } | ||
} | ||
|
||
private static Boolean ValidateInput( this Input input ) |
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.
@stazz, why isn't this method placed inside the Input
class itself?
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.
No particular reason. I guess the validity input depends a bit on a context (which I admit in this case is exactly one). Can move it as instance method of Input
class on Sunday.
|
||
public class GetVersion : GitVersionTaskBase | ||
public static class GetVersion |
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.
@stazz, why the change to static
here?
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.
Just like GenerateGitVersionInformation
(and one other task too), this class has no state on its own anymore, so no instances of it will be created either.
The So did I undestand you correctly @asbjornu that are you suggesting that I make a fresh fork out of the latest tip of GitVersion repository, and re-apply changes for NuGetUtils? That makes sense for me, as I have a feeling that the change log is now way too convoluted. The work load of doing so is not too big, IMO, as the changes were relatively straightforward, but I think I'll have time for that only on this Sunday. With the full re-apply of changes, I also hope it will be easier to see the reasoning behind the resulting |
Yes, exactly.
I'm very happy to hear that! Awesome!
👍 |
Resolved by #1677. |
Rebase of #1634. Resolves #1634.