methods in wrong services

[zyfy29]

go-github/github/repos_actions_permissions.go

Lines 34 to 39 in 06b8b3a

	// GetActionsPermissions gets the GitHub Actions permissions policy for repositories and allowed actions in a repository.
	//
	// GitHub API docs: https://docs.github.com/rest/actions/permissions#get-github-actions-permissions-for-a-repository
	//
	//meta:operation GET /repos/{owner}/{repo}/actions/permissions
	func (s *RepositoriesService) GetActionsPermissions(ctx context.Context, owner, repo string) (*ActionsPermissionsRepository, *Response, error) {

Methods in this file belong to ActionsService but wrongly separated to RepositoriesService.

Also:

go-github/github/enterprise_actions_hosted_runners.go

Lines 13 to 18 in 06b8b3a

	// ListHostedRunners lists all the GitHub-hosted runners for an enterprise.
	//
	// GitHub API docs: https://docs.github.com/enterprise-cloud@latest/rest/actions/hosted-runners#list-github-hosted-runners-for-an-enterprise
	//
	//meta:operation GET /enterprises/{enterprise}/actions/hosted-runners
	func (s *EnterpriseService) ListHostedRunners(ctx context.Context, enterprise string, opts *ListOptions) (*HostedRunners, *Response, error) {

and so on.

I'd like to create a pr to fix it, but it will introduce breaking API changes. Is that OK?

[zyfy29]

Also,

go-github/github/orgs_actions_allowed.go

Lines 12 to 19 in 06b8b3a

	// GetActionsAllowed gets the actions that are allowed in an organization.
	//
	// Deprecated: please use `client.Actions.GetActionsAllowed` instead.
	//
	// GitHub API docs: https://docs.github.com/rest/actions/permissions#get-allowed-actions-and-reusable-workflows-for-an-organization
	//
	//meta:operation GET /orgs/{org}/actions/permissions/selected-actions
	func (s *OrganizationsService) GetActionsAllowed(ctx context.Context, org string) (*ActionsAllowed, *Response, error) {

Here provides an alias for the wrong methods. It has been deprecated for nearly 2 years. Is it OK to be removed now?

[gmlewis]

So naming is a bit tricky/nuanced/flexible...

We have striven to match the structure in the official GitHub v3 API documentation. However, I must note that we have seen more than one significant reorganization of the official documentation over the years, so this is unfortunately a moving target.

Your first example might make sense to move, however, for your second example, an argument could be made that it is in the correct location due to its relationship to Enterprise.

As for deprecation and removal of methods, we have a serious problem in this repo because we continue to support Enterprise in addition to public GitHub. We have had to revert changes in the past due to requests from Enterprise users.

So I'm very hesitant to move/break/remove things unless there are really good reasons to, which does occasionally happen.

[gmlewis]

We can leave this issue open in case others have opinions.
If there is enough interest for particular methods, we can entertain moving them into their proper places.
Otherwise, i think it is best to wait on this.