Skip to content

ci: use org membership API for community label check#24149

Open
f0ssel wants to merge 1 commit intomainfrom
ci/community-label-public-membership-check
Open

ci: use org membership API for community label check#24149
f0ssel wants to merge 1 commit intomainfrom
ci/community-label-public-membership-check

Conversation

@f0ssel
Copy link
Copy Markdown
Member

@f0ssel f0ssel commented Apr 8, 2026

Supersedes #23343.

Problem

author_association on pull_request_target events is unreliable:

This causes org members to incorrectly receive the community label.

Approach

Replace the author_association check with an explicit orgs.checkMembershipForUser() API call, which reliably detects both public and private org members.

This requires a token with read:org scope. Rather than reusing a broad PAT like CDRCI_GITHUB_TOKEN (which raised concerns in #23343), this uses a new CODER_ORG_READ_TOKEN secret that should be a fine-grained PAT (or classic token) scoped to only read:org.

Setup required

A repo admin needs to:

  1. Create a PAT belonging to an org member with only read:org scope.
  2. Add it as a repository secret named CODER_ORG_READ_TOKEN.

Note

Generated by Coder Agents

@ethanndickson
Copy link
Copy Markdown
Member

ethanndickson commented Apr 8, 2026

The only theoretical miss is a private org member where author_association is also wrong — extremely unlikely, and the downside is just a removable label.

FWIW, most coder org members are private, so I'm not sure how useful this is. i.e. compare https://github.com/orgs/coder/people logged in vs logged out

Copy link
Copy Markdown
Member

@matifali matifali left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem is the members who do not have public membership. I am confused how this solves that? Because we cannot know whether they are members.
Do we just skip those PRs where a user's membership is set to private?

Does this also skip community members who have the org membership procedure?

@f0ssel
Copy link
Copy Markdown
Member Author

f0ssel commented Apr 8, 2026

I didn't understand the distinction between public and private membership, I'm taking a second look at this

@f0ssel
Copy link
Copy Markdown
Member Author

f0ssel commented Apr 8, 2026

In general, do we think asking devs to have public membership would be an okay path forward for something like this to work?

@matifali
Copy link
Copy Markdown
Member

matifali commented Apr 8, 2026

In general, do we think asking devs to have public membership would be an okay path forward for something like this to work?

Yeah, that would fix it without any changes needed, but I am not sure if everyone is OK about it.

Replace the flaky author_association check with an explicit org
membership API call (orgs.checkMembershipForUser) which reliably
detects both public and private org members.

author_association is unreliable because:
- It returns CONTRIBUTOR instead of MEMBER when both apply.
- It returns NONE for members with private org visibility.

This uses a dedicated CODER_ORG_READ_TOKEN secret scoped to only
read:org, avoiding the need to reuse a broader PAT. A repo admin
needs to create this token and add it as a repository secret.

Supersedes #23343.
@f0ssel f0ssel force-pushed the ci/community-label-public-membership-check branch from 400ef8d to 74600f0 Compare April 8, 2026 15:14
@f0ssel f0ssel changed the title ci: use public membership API for community label check ci: use org membership API for community label check Apr 8, 2026
@f0ssel
Copy link
Copy Markdown
Member Author

f0ssel commented Apr 8, 2026

@jdomeracki-coder Does this seem like something we are okay with? Could you make this secret exist if possible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants