ORGANIZATION_NAME and PROJECT_NAME didn't work as expected

[aadsm]

I followed the guide on publishing to github and used GIT_USER=aadsm ORGANIZATION_NAME=aadsm PROJECT_NAME=draft-js CURRENT_BRANCH=docusaurus USE_SSH=true npm run publish-gh-pages to publish to my own fork of draft.js.

I was expecting the aadsm/draft-js#gh-pages branch to be updated but in reality facebook/draft-js#gh-pages was instead!
I haven't debug why, I'm assuming that at some point the configuration I have on siteConfig.js was used but I don't think this should have happened.

[JoelMarcey]

Hi @aadsm. Yeah, if you have organizationName set in siteConfig.js set, that currently takes precedent. https://github.com/facebook/Docusaurus/blob/master/lib/publish-gh-pages.js#L23

const ORGANIZATION_NAME =
  siteConfig.organizationName ||
  process.env.ORGANIZATION_NAME ||
  process.env.CIRCLE_PROJECT_USERNAME;

We can discuss whether that should be the case. I can see the argument that manually set environment variables should take precedent, but at the time we thought that all siteConfig variables should be first in line.

But, we definitely don't want you publishing to an unexpected place - so we should figure something out that makes that not happen again.

[aadsm]

Oh I see. I assumed that these would override any siteConfig options as that's usually what happens with these type of variables.
Take as an example git, if you set the GIT_AUTHOR_NAME environment variable then this will take precedent to the git configuration: https://git-scm.com/book/gr/v2/Git-Internals-Environment-Variables#_committing

[julen]

Just adding a note to mention I also hit this unexpected behavior. Same as @aadsm, I was expecting explicitly set environment variables to take precedence over any configuration set in siteConfig.js.

[JoelMarcey]

Seems reasonable that we should reverse the precedent. Anyone want to submit a PR here?

[juanpicado]

Me 👍