Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Set more environment variables to allow their use in custom hooks #316

Closed
afdev82 opened this issue Nov 30, 2016 · 10 comments
Closed

Set more environment variables to allow their use in custom hooks #316

afdev82 opened this issue Nov 30, 2016 · 10 comments
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.
Milestone

Comments

@afdev82
Copy link
Contributor

afdev82 commented Nov 30, 2016

In order to write custom hooks that use some variables, Gitea should export them in the environment.

For example, currently I need to know the user that is pushing a branch.
I think this could be easily done adding an os.Setenv line like here.

@afdev82 afdev82 changed the title Set more environment variables to allow their use custom hooks Set more environment variables to allow their use in custom hooks Nov 30, 2016
@lunny lunny added type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Nov 30, 2016
@tboerger tboerger added this to the 1.0.0 milestone Nov 30, 2016
@strk
Copy link
Member

strk commented Dec 2, 2016

#317 adds one such variable, do you have a list of variables you think should be exposed ?

@afdev82
Copy link
Contributor Author

afdev82 commented Dec 2, 2016

@strk Yes, I opened the #317 😛
I don't have a list, I think it's enough to know the user that is pushing (for my actual needs).
I saw that also the gogs/gogs#3921, I think we should agree how many variables to expose and document that.
I exported the name, because I don't think it's a good idea to expose the id. IMHO for a custom hook it would be enough to have the name (to whitelist it).

@lunny lunny modified the milestones: 1.1.0, 1.0.0 Dec 3, 2016
@lunny
Copy link
Member

lunny commented Dec 3, 2016

since #317 is in 1.1, so I change this to 1.1

@tboerger
Copy link
Member

tboerger commented Dec 3, 2016

I would take that into the 1.0 release because users like @afdev82 are able to provide hooks for protected branches until we release native protected branches. This change is quite simple.

@lunny
Copy link
Member

lunny commented Dec 4, 2016

Then what's the status of #317? If #317 will be merged in 1.0, this could be changed to 1.0

@tboerger
Copy link
Member

tboerger commented Dec 4, 2016

It just needs another lgtm

@bkcsoft bkcsoft closed this as completed in 947d2ee Dec 5, 2016
@bkcsoft
Copy link
Member

bkcsoft commented Dec 5, 2016

@afdev82 was this supposed to be closed with #317 ? otherwise feel free to reopen it (it got closed automagically by merging 317)

@afdev82
Copy link
Contributor Author

afdev82 commented Dec 5, 2016

@bkcsoft Yes, it's fine. Thanks ;)

@afdev82
Copy link
Contributor Author

afdev82 commented Dec 5, 2016

I didn't understand the target version, I thought was the 1.0.0 release in the end.

@tboerger tboerger modified the milestones: 1.0.0, 1.1.0 Dec 5, 2016
@tboerger
Copy link
Member

tboerger commented Dec 5, 2016

You are right, it will be available for 1.0.0

@go-gitea go-gitea locked and limited conversation to collaborators Nov 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type/enhancement An improvement of existing functionality type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Development

No branches or pull requests

5 participants