GCP Cherry pick boot is not working for our repo about repo-automation-bots

[neil-hickey]

👋 Hi @chingor13 ! Yes, the PR submitters are owners / maintainers. Unfortunately there's no feedback from the bot, so I suspect maybe it's just not seeing the PR? Not sure!

We are all part of a "group" "team" on github instead of individual access on the repo. Do you think this would matter?

UPDATE:

Yep, the group team matters. Apparently the bot does not support groups teams, you have to be individually added to the repo. That was unexpected! Any idea if this is a bug or feature? :)

[chingor13]

One thing to check is that the person attempting to do the cherry pick is an invited collaborator, owner, or member of the organization. This was a security feature to avoid abuse/unwanted use of the bot.

Collaborator is not included in the list of allowed roles. This is because (IIRC) a collaborator is someone who has submitted a PR that's been previously been submitted and is not a maintainer of the repo. This bot is intended to be used by maintainers of the repo.

Code refs:

repo-automation-bots/packages/cherry-pick-bot/src/bot.ts

Lines 33 to 38 in ebbe2c8

	// See https://docs.github.com/en/graphql/reference/enums#commentauthorassociation
	const ALLOWED_COMMENTER_ASSOCIATIONS = new Set([
	'COLLABORATOR', // Author has been invited to collaborate on the repository.
	'OWNER', // Author is the owner of the repository.
	'MEMBER', // Author is a member of the organization that owns the repository.
	]);

repo-automation-bots/packages/cherry-pick-bot/src/bot.ts

Lines 75 to 84 in ebbe2c8

	if (
	!ALLOWED_COMMENTER_ASSOCIATIONS.has(
	context.payload.comment.author_association
	)
	) {
	logger.debug(
	`comment author (${context.payload.comment.author_association}) is not authorized to cherry-pick`
	);
	return;
	}

[chingor13]

Any idea if this is a bug or feature?

The bot is only using the data available directly from the webhook. There are other API endpoints to query membership status (IIRC), but these often require extra permissions. This was not an intended feature as our use-case is usually encapsulated by organization membership.

Is your repo part of an organization? By group, do you mean a GitHub team?

[neil-hickey]

Any idea if this is a bug or feature?

The bot is only using the data available directly from the webhook. There are other API endpoints to query membership status (IIRC), but these often require extra permissions. This was not an intended feature as our use-case is usually encapsulated by organization membership.

Is your repo part of an organization? By group, do you mean a GitHub team?

Our repo is part of an organization, and yep a github team. (https://github.com/orgs/carvel-dev/teams/our-team)

[chingor13]

I can't find a definitive source on how GitHub decides which enum to give to the comment's author_association. If CONTRIBUTOR is considered a higher privilege tier than MEMBER (even though CONTRIBUTOR could include folks outside), then I think we don't want to allow that level by default (the current behavior).

It might be possible to add a feature/configuration to opt-in the repository to allow CONTRIBUTORS to use the bot (or perhaps configure the entire list of allowed author associations).

[neil-hickey]

Our github team is all admin. So we have the higher permissions than contributors / members regardless. Just seems like the team aspect doesn't work, but when I add myself as an individual member with admin- it works.

We got a work around for now, but it's kind of a pain and IMO defeats the purpose of teams.