Also fetching the github enterprise openAPI specs, and appending them

[DocEmmetBrown]

I needed a way to mock some enterprise calls, so I added a new API endpoint URL.
In order to have consistent output, since both endpoint have a lot in common, I had to add a quick & dirty struct just there to "uniq" the entries.
I did not touch any of the code logic, as it worked perfectly out of the box.
Thanks for the hard work building this library, that is super helpful !

[migueleliasweb]

Thanks for the contribution, @DocEmmetBrown !

Would this be somewhat similar to using the example in the README about Github Enterprise? https://github.com/migueleliasweb/go-github-mock?tab=readme-ov-file#mocking-for-github-enterprise.

I'm not sure if the endpoints are fundamentally different or the diff is only a prefix.

[DocEmmetBrown]

Hey @migueleliasweb,
I'm not familiar with how WithRequestMatchEnterprise works, but I was looking at very specific endpoints that I did not see in the current version, namely the following:

var GetOrgsAuditLogByOrg EndpointPattern = EndpointPattern{
	Pattern: "/orgs/{org}/audit-log",
	Method:  "GET",
}

and a few others

[migueleliasweb]

I was digging a bit checking the diff between the two openapi definitions for the normal and enterprise versions. They are very similar but the enterprise has some extra bits, which I think it makes sense.

Could you generate the enterprise EndpointPattern in a separate file to make it easier to distinguish between implementations? Also, did you have to add an uniq due to the similarities between the two? I wonder if adding a prefix wouldn't make this go away.

Cheers.

[DocEmmetBrown]

Could you generate the enterprise EndpointPattern in a separate file to make it easier to distinguish between implementations?
That's what I did at first, but there were so many absolutely identical calls, that I had errors. The enterprise API OpenAPI definition contains all the calls including /repos/* and so on...

Also, did you have to add an uniq due to the similarities between the two? I wonder if adding a prefix wouldn't make this go away.

If you prefer, we could add a prefix for enterprise calls, and have them in another file. In that case, we would have :

var GetReposPullsByOwnerByRepo EndpointPattern = EndpointPattern{
	Pattern: "/repos/{owner}/{repo}/pulls",
	Method:  "GET",
}

and

var GetEnterpriseReposPullsByOwnerByRepo EndpointPattern = EndpointPattern{
	Pattern: "/repos/{owner}/{repo}/pulls",
	Method:  "GET",
}

but they would ultimately call the exact same endpoint, so I'm wondering if it's adding a lot of value 🤔

Tell me what you'd like, and I'll come with a solution.

[DocEmmetBrown]

Hey @migueleliasweb ,
tell me which implementation solution you prefer, and I'll adapt the PR ;)

[DocEmmetBrown]

ping @migueleliasweb ;)

[migueleliasweb]

Hi @DocEmmetBrown , sorry for the delay. Life's been busy.

So, I understand there are a bit of overlap between the two but I think it's a bit better o have the two being generated fully.

Could you just, instead, create a new gen_enterprise.go and put all the endpoint patterns there?

I'm happy to merge with that.

Thanks for the contribution.

Edit:

With the new file and the Enterprise prefix, I don't think you'll need the uniq map anymore. Is that right?

[DocEmmetBrown]

With the new file and the Enterprise prefix, I don't think you'll need the uniq map anymore. Is that right?

I think that's correct. I will try that path, and update my PR. Thanks for your time.

[DocEmmetBrown]

Hey @migueleliasweb,
I gave it a go with the new methodology.

I'm not 100% happy with it, but it works.
I think the code could benefit from some clean-up, especially adding an "actual" config package would probably be nicer, but for now, it does what it is supposed to do :)
And it's also fairly easy to add new api specs if needed.

I left the previous commit, so that you can iterate between both methods to see what you prefer.

Tell me how you feel about it.

Cheers