Added missing fields for deployments API

[hansmbakker]

The Deployments API is missing these fields:

• ref
• environment
• original_environment

This PR adds them.

They are documented at https://docs.github.com/en/rest/deployments/deployments#list-deployments.

[hansmbakker]

Note: there is a test that checks

Assert.Equal("topic-branch", actual.Sha);

but actual.Sha should be a SHA and topic-branch should be in the ref property.

Also, I am wondering why all URLs are parsed as string rather than proper Uris?

[JonruAlveus]

Hi @hansmbakker, thanks for the PR! Please feel free to fix any tests that you think look a bit odd!

I'm not sure if it's a requirement of the de-serializer but URLs are always strings here. This is something we could look into when we move to auto-generated models.

[hansmbakker]

I'm not sure if it's a requirement of the de-serializer

@JonruAlveus it is not a requirement, I already have them working with Uris. The reason I did not include them here is that I thought that my PR would be declined for backwards-compatibility reasons if I updated those fields. If you're open to them being Uris I will update my PR

[hansmbakker]

Please feel free to fix any tests that you think look a bit odd!

@JonruAlveus In general the response from the API in practice seems to have changed a bit since the test was written. For me, the payload field is empty and the environment has become its own field on root level.

[hansmbakker]

Also: what C# / dotnet versions are OK to be used in the tests?
Currently only old TargetFrameworks are enabled in the Octokit.Tests project - I would say those could use an upgrade?

[hansmbakker]

• JSON and asserts in DeploymentTests are fixed
• Added net6.0 to test projects

[nickfloyd]

Hey @hansmbakker, Thanks for the change set here! ❤️ It looks like @JonruAlveus already has you covered on the review front. I did want to highlight that as we've been modifying these models, we've been updating the property accessors to be the more appropriate private instead of protected.

There is no way you would've known this unless you've watched the PRs over the past few months. I've got an incoming PR that has done a sweep to unify all of our Response models under this approach - just giving you a heads up here in case you wanted to change this one as well. Not a blocker, though.

Thanks again for the changes.

Suggested change

	public string Ref { get; protected set; }
	public string Ref { get; private set; }

[hansmbakker]

@nickfloyd should it not be { get; init; } then since they are only set in the constructor?
And with that, should those models not be records rather than classes?

[nickfloyd]

Hey @hansmbakker { get; init; } would certainly be a much more semantically rich way to write this, but we cannot make that jump just yet for 2 reasons:

• We're using c# 7.3, and init is only supported in >= 9.x
• In the hydration logic for the SDKs for incoming responses uses reflection that expects a certain structure. Until we're ready to rewrite those things we'll need to drive to consistency incrementally.

[hansmbakker]

@nickfloyd thanks for the explanation.

With that - #2562 would be beneficial for several reasons.

[nickfloyd]

@hansmbakker, I 100% agree. I look forward to working as a community to drive changes like your suggested. Certain things just can't / shouldn't be generated, and whatever we can use to drive down complexity would be a win for this SDK! ❤️

[hansmbakker]

@JonruAlveus @nickfloyd thank you for the feedback - I have one open question left, could you help me with it?

Is it ok for me to use Uri instead of string to make the uri properties semantically correct?

[nickfloyd]

For reference: #2565

[nickfloyd]

@JonruAlveus @nickfloyd thank you for the feedback - I have one open question left, could you help me with it?

Is it ok for me to use Uri instead of string to make the uri properties semantically correct?

While we are driving toward consistency, I'd recommend sticking with string as the type. I know this is not ideal, and I normally favor using appropriate types. The only reason I'd say stick with string is for consistency's sake. Since we are pushing on the auto-generation front, keeping things more consistent (even if it's not 100% semantically correct in what we have should lower the barrier to generation in the future.

Given that, I'll leave the decision up to you. Either way, we'll be able to work with it, and I don't want to block your solid changes here over a semantic speed bump.

[nickfloyd]

LGTM! ❤️

[hansmbakker]

@nickfloyd thank you! I switched protected set to private set and will leave the uris as String now.

@JonruAlveus could you please review this?

[nickfloyd]

release_notes: Adds missing fields for deployments API