Add GITEA_REPO_MEMBERS_EMAILS env key for hooks #7918

Closed
opened 2025-11-02 07:41:27 -06:00 by GiteaMirror · 8 comments
Owner

Originally created by @ivptr on GitHub (Sep 30, 2021).

Feature Description

It would be nice to add GITEA_REPO_MEMBERS_EMAILS environment key, containing emails of all users having access to repository (collaborators, owners and its team members).

That way it would be possible to send email notifications about commits to all involved parties, as mentioned in #1457.

Screenshots

No response

Originally created by @ivptr on GitHub (Sep 30, 2021). ### Feature Description It would be nice to add GITEA_REPO_MEMBERS_EMAILS environment key, containing emails of all users having access to repository (collaborators, owners and its team members). That way it would be possible to send email notifications about commits to all involved parties, as mentioned in #1457. ### Screenshots _No response_
GiteaMirror added the type/proposalreviewed/wontfix labels 2025-11-02 07:41:27 -06:00
Author
Owner

@zeripath commented on GitHub (Sep 30, 2021):

Which kind of hook do you mean here? a githook?

@zeripath commented on GitHub (Sep 30, 2021): Which kind of hook do you mean here? a githook?
Author
Owner

@wxiaoguang commented on GitHub (Oct 1, 2021):

Another question, what is the purpose of "sending email notifications about commits"? In old days people liked to know the committing actions, but as today, the code repository becomes larger and larger, most people do not care about every trivial commit anymore.

I also do not think passing emails via environment is a good idea. Think about you have a large org contains more than a thousand users, the environment will be filled by a lot of emails which are not very useful.

@wxiaoguang commented on GitHub (Oct 1, 2021): Another question, what is the purpose of "sending email notifications about commits"? In old days people liked to know the committing actions, but as today, the code repository becomes larger and larger, most people do not care about every trivial commit anymore. I also do not think passing emails via environment is a good idea. Think about you have a large org contains more than a thousand users, the environment will be filled by a lot of emails which are not very useful.
Author
Owner

@ivptr commented on GitHub (Oct 2, 2021):

This feature request is in line with explanation for post-receive Git hook:
https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
"The post-receive hook runs after the entire process is completed and can be used to update other services or notify users":

I just want to notify all users having access to repository (collaborators, owners and its team members).

Is there another way to fetch such emails if GITEA_REPO_MEMBERS_EMAILS environment key is a no go? Maybe calling /usr/local/bin/gitea using some param?

@ivptr commented on GitHub (Oct 2, 2021): This feature request is in line with explanation for `post-receive` Git hook: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks "The post-receive hook runs after the entire process is completed and can be used to update other services or **notify users**": I just want to notify all users having access to repository (collaborators, owners and its team members). Is there another way to fetch such emails if GITEA_REPO_MEMBERS_EMAILS environment key is a no go? Maybe calling `/usr/local/bin/gitea` using some param?
Author
Owner

@wxiaoguang commented on GitHub (Oct 2, 2021):

Gitea has API: https://try.gitea.io/api/swagger#/repository/repoListCollaborators

@wxiaoguang commented on GitHub (Oct 2, 2021): Gitea has API: https://try.gitea.io/api/swagger#/repository/repoListCollaborators
Author
Owner

@ivptr commented on GitHub (Oct 2, 2021):

API seems to be overkill for this, it needs ENABLE_SWAGGER enabled and authorization.

Also that lists collaborators only, how about owners and its team members?

Is it possible to get such data using Gitea command line, similar to /usr/local/bin/gitea -c /etc/gitea/app.ini admin user list

@ivptr commented on GitHub (Oct 2, 2021): API seems to be overkill for this, it needs ENABLE_SWAGGER enabled and authorization. Also that lists collaborators only, how about owners and its team members? Is it possible to get such data using Gitea command line, similar to `/usr/local/bin/gitea -c /etc/gitea/app.ini admin user list`
Author
Owner

@noerw commented on GitHub (Oct 8, 2021):

I agree that for your use case using the API instead of hardcoded, instance-wide variables is much cleaner.

Exposing this specific env variable is not a reasonable request.
What might be an option, is to add a config option with an allow list of env vars on the gitea process that are passed through to git hooks, though I doubt there is much demand for such a feature

@noerw commented on GitHub (Oct 8, 2021): I agree that for your use case using the API instead of hardcoded, instance-wide variables is much cleaner. Exposing this specific env variable is not a reasonable request. What might be an option, is to add a config option with an allow list of env vars on the gitea process that are passed through to git hooks, though I doubt there is much demand for such a feature
Author
Owner

@ivptr commented on GitHub (Oct 9, 2021):

This should be accessible from command line. Also it lacks owners/team members info.

Ended up with SQL queries:

mailingList = [pusher_email]

# Get owner's email when it's not organization
rows_count = cursor.execute("SELECT email FROM repository, user WHERE repository.name = %s AND repository.owner_name = %s AND user.id=repository.owner_id AND user.type=0", (repoName, repoUserName))
records = cursor.fetchall()
for row in records:
	mailingList.append(str(row[0]))

# Get collaborators' emails
rows_count = cursor.execute("SELECT email FROM repository, user, collaboration WHERE repository.name = %s AND repository.owner_name = %s AND collaboration.repo_id=repository.id AND collaboration.user_id=user.id", (repoName, repoUserName))
records = cursor.fetchall()
for row in records:
	mailingList.append(str(row[0]))

# Get organization team members' emails
rows_count = cursor.execute("SELECT email FROM user, team_user WHERE team_user.uid=user.id AND team_user.team_id IN (SELECT team.id FROM repository, user, team WHERE repository.name = %s AND repository.owner_name = %s AND user.id=repository.owner_id AND user.type=1 AND team.org_id=user.id)", (repoName, repoUserName))
records = cursor.fetchall()
for row in records:
	mailingList.append(str(row[0]))
@ivptr commented on GitHub (Oct 9, 2021): This should be accessible from command line. Also it lacks owners/team members info. Ended up with SQL queries: ``` mailingList = [pusher_email] # Get owner's email when it's not organization rows_count = cursor.execute("SELECT email FROM repository, user WHERE repository.name = %s AND repository.owner_name = %s AND user.id=repository.owner_id AND user.type=0", (repoName, repoUserName)) records = cursor.fetchall() for row in records: mailingList.append(str(row[0])) # Get collaborators' emails rows_count = cursor.execute("SELECT email FROM repository, user, collaboration WHERE repository.name = %s AND repository.owner_name = %s AND collaboration.repo_id=repository.id AND collaboration.user_id=user.id", (repoName, repoUserName)) records = cursor.fetchall() for row in records: mailingList.append(str(row[0])) # Get organization team members' emails rows_count = cursor.execute("SELECT email FROM user, team_user WHERE team_user.uid=user.id AND team_user.team_id IN (SELECT team.id FROM repository, user, team WHERE repository.name = %s AND repository.owner_name = %s AND user.id=repository.owner_id AND user.type=1 AND team.org_id=user.id)", (repoName, repoUserName)) records = cursor.fetchall() for row in records: mailingList.append(str(row[0])) ```
Author
Owner

@zeripath commented on GitHub (Oct 9, 2021):

This is a substantial amount of data that would have to be generated for every single git request. Data that is not used by our hooks and therefore not by every user or repo.

We've been very careful to state that we do not consider the environment variables that Gitea sets for git hooks to represent a form of API and that whilst they have been (relatively) stable we will not promise this and we will not consider changes to them to be breaking. We will not add additional data that we would not use.

Please use the API or add the functionality directly to Gitea where it could be turned off or only used on repos that it is appropriate for.

@zeripath commented on GitHub (Oct 9, 2021): This is a substantial amount of data that would have to be generated for every single git request. Data that is not used by our hooks and therefore not by every user or repo. We've been very careful to state that we do not consider the environment variables that Gitea sets for git hooks to represent a form of API and that whilst they have been (relatively) stable we will not promise this and we will not consider changes to them to be breaking. We will not add additional data that we would not use. Please use the API or add the functionality directly to Gitea where it could be turned off or only used on repos that it is appropriate for.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#7918