Skip to content

avoid os.Setenv calls in runServ, add env vars to gitcmd.Env instead #3772

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

Closed
wants to merge 3 commits into from

Conversation

ilius
Copy link

@ilius ilius commented Apr 9, 2018

Using os.Setenv() is the middle of a running program is very unsafe, specially if some vars are set conditionally (their effect will remain until the program is running)

I think the only reason we set these env vars is because of running the git command gitcmd.Run().
Please correct me if I'm wrong.
For the gitcmd.Run(), we just need to add vars to gitcmd.Env, without effecting the global env vars.

EDIT: I realized this part of program does not stay running (and there is no concurrency) because it's compiled to a serv binary and runs for each operation.
But it's still cleaner this way and a better practice in general.

@codecov-io
Copy link

codecov-io commented Apr 9, 2018

Codecov Report

❗ No coverage uploaded for pull request base (master@4b84928). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #3772   +/-   ##
=========================================
  Coverage          ?   37.61%           
=========================================
  Files             ?      310           
  Lines             ?    46040           
  Branches          ?        0           
=========================================
  Hits              ?    17319           
  Misses            ?    26242           
  Partials          ?     2479

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4b84928...5817c2e. Read the comment docs.

@bkcsoft bkcsoft added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Apr 9, 2018
@lafriks lafriks added the type/refactoring Existing code has been cleaned up. There should be no new functionality. label Apr 9, 2018
cmd/serv.go Outdated
@@ -151,13 +151,15 @@ func runServ(c *cli.Context) error {
reponame = reponame[:len(reponame)-5]
}

os.Setenv(models.EnvRepoUsername, username)
env := map[string]string{}
Copy link
Contributor

Choose a reason for hiding this comment

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

I would prefer to avoid using a map and then joning all of its keys (maps are quite expensive to allocate and env vars will always be in random order because of how range works on maps) - can't you use a bytes.Buffer instead?

Copy link
Author

Choose a reason for hiding this comment

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

I changed it to []string, the same thing that we need to give to the command (gitcmd.Env)

cmd/serv.go Outdated
os.Setenv(models.EnvRepoUsername, username)
env := map[string]string{}

env[models.EnvRepoUsername] = username
Copy link
Contributor

Choose a reason for hiding this comment

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

... and make these buf.WriteString(models.EnvRepoUsername + "=" + username + "\n") etc. instead?

Copy link
Author

Choose a reason for hiding this comment

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

We will need to convert it to []string at the end (strings.Split). I don't think using buffer is worth it (we don't set too many env vars)

@stale
Copy link

stale bot commented Jan 4, 2019

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs during the next 2 months. Thank you for your contributions.

@stale stale bot added the issue/stale label Jan 4, 2019
@stale
Copy link

stale bot commented Mar 5, 2019

This pull request has been automatically closed because of inactivity. You can re-open it if needed.

@stale stale bot closed this Mar 5, 2019
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/stale lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. type/refactoring Existing code has been cleaned up. There should be no new functionality.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants