Selective deduplication of openapi parameters.

[peterschutt]

Ignores duplicate parameters that are equal in name and type.

Raises ImproperlyConfiguredException for duplicate parameters that differ in type.

For #127

[peterschutt]

@Goldziher I'll work on #128 next, so don't worry about another release until I have that done - I doubt this is affecting many people in a meaningful way.

[Goldziher]

Good stuff

[Goldziher]

PR is approved - for the next PRs, simply create a branch in the repository of starlite, this way sonar and snyk will run with the tokens and you will get a coverage report as well.

I leave it to you to merge when ready.

[peterschutt]

OK cool, I was wondering about those. Does this sound good for workflow?

1. create a feature branch in starlite
2. do the work in my fork
3. PR into the feature branch
4. PR feature into main (this is where snyk and sonar should run?)

What do you think we should do for contributors? Perhaps we could have a dev branch that is periodically merged into main for releases?

[Goldziher]

So, only collaborators with write access can actually branch inside starlite.

I'd say the regular workflow of forking is good enough mostly.

We could use version branches rather than commit directly to main, but I don't see the benefit at the volume we are working at present - everything in general is reviewed aside from minor version bumps etc.

If you strongly prefer it though, we could go for such a process ofc.

[peterschutt]

Agree with keeping it simple. So sonar and snyk run for contributor code on merge into main?

[Goldziher]

Sonar and snyk require a token that is a repo secret, so it works only on branches in this repo.

I tried gating them not to run on forks, but failed. I should spend some time on it... But it's really low prio for me.

[peterschutt]

Yep no worries, def. not a major priority.