Skip to content
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

Fix Issue Timeline exceptions by adding new EventInfoState values #1563

Merged
merged 6 commits into from
Apr 2, 2017

Conversation

ryangribble
Copy link
Contributor

@ryangribble ryangribble commented Mar 11, 2017

Fixes #1559
Fixes #1525

This fix adds 3 more undocumented event types in the TimeLine API: linecommented commitcommented and reviewed

Also added an integration test that will hopefully help with identifying more missing values in the future, it now runs against the most recent 20 closed PRs and 20 open issues in a heavy activity repository.

I picked Microsoft/vscode 😀 the theory being that it's a very active repository, and the most recent activity is more likely to have new event types in their timeline/event stream.

The strategy seemed to work, as I discovered 2 extra event types that hadn't been reported by users as causing a crash yet 😸

In the short term, we will still throw an exception whenever we encounter an event type not previously implemented, a potential longer term solution is being hashed out in #1504

@ryangribble
Copy link
Contributor Author

If someone can have a 👀 over this before I merge it, that would be great! 😀

@ryangribble ryangribble added bug and removed bug labels Mar 11, 2017
/// A line comment was made.
/// </summary>
[SuppressMessage("Microsoft.Naming", "CA1704:IdentifiersShouldBeSpelledCorrectly", MessageId = "Linecommented")]
Linecommented,
Copy link
Member

Choose a reason for hiding this comment

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

Could these be cased as LineCommented and CommitCommented? Or is this a deserialization issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The API value is all lowercase, pretty sure if we do camel case on our side we'll be looking for an underscore in the API value

Copy link
Member

@shiftkey shiftkey Mar 13, 2017

Choose a reason for hiding this comment

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

@ryangribble I thought we could do something like this here?

[Parameter(Value = "linecommented")]
LineCommented,
[Parameter(Value = "commitcommented")]
CommitCommented

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah so on looking into this more I realised we dont even need to tag with the Parameter() since these are only response enums and our deserializer removes underscores and does a case insensitive Enum.Parse() anyway 👍

{
var timelineEventInfos = await _issueTimelineClient.GetAllForIssue("microsoft", "vscode", issue.Number);

Assert.NotNull(timelineEventInfos);
Copy link
Member

Choose a reason for hiding this comment

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

Assert.NotEmpty here too?

@shiftkey
Copy link
Member

@ryangribble left a couple of minor comments, everything else is 💎

@eriawan
Copy link
Contributor

eriawan commented Mar 13, 2017

@ryangribble just a suggestion, I think it's easier to suppress CA warnings as project scope instead of class/method/property scope for CA rule of 1704. 🙂
This rule is mostly pedantic in a sense it will limit the expressiveness of naming class/method/property, and it's easier and faster (in compile time) to just suppress it on project scope, not at different source on class/method/property.

@shiftkey
Copy link
Member

This rule is mostly pedantic in a sense it will limit the expressiveness of naming class/method/property, and it's easier and faster (in compile time) to just suppress it on project scope, not at different source on class/method/property.

I disagree. The explicitness of this rule means violations (whether necessary or otherwise) are easier to identify. Doing things at a project level makes it easier to ignore these sorts of issues.

@ryangribble
Copy link
Contributor Author

@shiftkey should be good now. I also agree on minimising the number of code analysis rules we "opt out" of at a project level 👍

@shiftkey
Copy link
Member

@ryangribble ugh, CI failures on macOS

The command "curl -o "/tmp/mdk.pkg" -fL http://download.mono-project.com/archive/4.2.3/macos-10-x86/MonoFramework-MDK-4.2.3.macos10.xamarin.x86.pkg" failed and exited with 56 during .

@ryangribble
Copy link
Contributor Author

kicked the builds and they are ✅ now

@ryangribble
Copy link
Contributor Author

@shiftkey not sure if you wanted to close out reviewing this or not. Ill merge it in a day or two if I haven't heard back

@shiftkey
Copy link
Member

shiftkey commented Apr 2, 2017

@ryangribble :shipit:

@ryangribble
Copy link
Contributor Author

ryangribble commented Aug 18, 2017

release_notes: Fix more IssueTimelineClient deserialization exceptions by adding more new EventInfoState values

@nickfloyd nickfloyd added Type: Bug Something isn't working as documented and removed category: bug labels Oct 26, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug Something isn't working as documented
Projects
None yet
4 participants