Skip to content

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

Closed
wants to merge 12 commits into from
Closed

Conversation

asbjornu
Copy link
Member

Rebase of #1634. Resolves #1634.

@asbjornu
Copy link
Member Author

This is puzzling. This PR is just a rebase of #1634 (so all the merge commits are removed), but the build fails on this while it's successful in #1634. Any ideas why, @arturcic?

@arturcic
Copy link
Member

Looks like everywhere the same test is failing OutputsShouldMatchVariableProvider

@asbjornu
Copy link
Member Author

Any ideas why that fails here and not in #1634, @arturcic? I don't get it.

@arturcic
Copy link
Member

arturcic commented Mar 22, 2019

Not really, we need to check if there is any difference between these 2 branches

@asbjornu asbjornu force-pushed the feature/NuGetUtilsUpdate branch from 3ef9634 to 3f525c4 Compare March 22, 2019 12:35
@asbjornu
Copy link
Member Author

@arturcic, I did a fresh git reset and git rebase now and that seems to have fixed the problem. Things are at least green. 🤷‍♂️

@arturcic
Copy link
Member

Great! My question is why do we have 2 PRs?

@asbjornu
Copy link
Member Author

Just to get rid of these: c2f3610, 9d8eb38, b608f96, 854f16b.

@arturcic
Copy link
Member

So I guess this PR will get merged instead of the other one

@asbjornu
Copy link
Member Author

Yes, this resolves #1634 so as soon this is merged, it will be closed automatically. It would be neat if GitHub supported rebase instead of merge for the "Update branch" button, but alas it doesn't. I've just installed Autorebase which might help us with that. I'll try that on #1634 shortly.

@asbjornu
Copy link
Member Author

Sigh. Seems like my rebase failed for some reason.

@asbjornu asbjornu force-pushed the feature/NuGetUtilsUpdate branch from 37b2aa1 to 99300d1 Compare March 24, 2019 18:55
@asbjornu
Copy link
Member Author

asbjornu commented Mar 24, 2019

Thanks for figuring that out, @dazinator. I think I got the rebase right now, but notice that 3b28212 (and my rebased de31124) reintroduces the Logger.Reset() calls that @tpaxatb removed in #1644. I suppose that's a mistake, @stazz?

@tpaxatb
Copy link
Contributor

tpaxatb commented Mar 25, 2019

Thanks for figuring that out, @dazinator. I think I got the rebase right now, but notice that 3b28212 (and my rebased de31124) reintroduces the Logger.Reset() calls that @tpaxatb removed in #1644. I suppose that's a mistake, @stazz?

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...)

@asbjornu
Copy link
Member Author

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?

@arturcic
Copy link
Member

Agree

@stazz
Copy link
Contributor

stazz commented Mar 25, 2019

@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 IBuildEngine in some special way? I think no, but maybe @tpaxatb can shed some insight on this? Currently the task factory is using the IBuildEngine provided in Initialize method when it performs pre-checks, and the task proxy will just redirect all output of invoked task to the IBuildEngine that it receives.

@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 .

@stazz
Copy link
Contributor

stazz commented Mar 27, 2019

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.

@stazz
Copy link
Contributor

stazz commented Mar 27, 2019

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 2.0.5, and updated my fork.

@asbjornu asbjornu force-pushed the feature/NuGetUtilsUpdate branch from 99300d1 to e6a6bec Compare April 10, 2019 08:25
@asbjornu asbjornu requested a review from dazinator April 10, 2019 08:36
@feitzi
Copy link

feitzi commented May 6, 2019

any updates?

@stazz
Copy link
Contributor

stazz commented May 8, 2019

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).
@dazinator @asbjornu if I need to still do something, feel free to instruct what needs to be done. :)

@asbjornu asbjornu force-pushed the feature/NuGetUtilsUpdate branch from e6a6bec to 1a09bc3 Compare May 8, 2019 10:23
Copy link
Member Author

@asbjornu asbjornu left a 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
Copy link
Member Author

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?

Copy link
Contributor

@stazz stazz May 8, 2019

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.

Copy link
Member Author

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
Copy link
Member Author

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)?

Copy link
Contributor

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.

Copy link
Member Author

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 )
Copy link
Member Author

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?

Copy link
Contributor

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
Copy link
Member Author

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?

Copy link
Contributor

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.

@stazz
Copy link
Contributor

stazz commented May 8, 2019

The static is because there is no longer need to extend ITask. Instead, the entrypoint acts just like a normal C# entrypoint, with an addition of having complex typed parameters (and not just String[]). That pretty much eliminates the need to use class hierarchy for the tasks contained in the assembly as well.

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 static entrypoints and no class hierarchy for tasks.

@asbjornu
Copy link
Member Author

asbjornu commented May 9, 2019

@stazz:

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?

Yes, exactly.

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.

I'm very happy to hear that! Awesome!

With the full re-apply of changes, I also hope it will be easier to see the reasoning behind the resulting static entrypoints and no class hierarchy for tasks.

👍

@stazz
Copy link
Contributor

stazz commented May 12, 2019

@asbjornu This is now opened as #1677 . :)

@asbjornu
Copy link
Member Author

Resolved by #1677.

@asbjornu asbjornu closed this May 20, 2019
@asbjornu asbjornu deleted the feature/NuGetUtilsUpdate branch May 20, 2019 07:11
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.

6 participants