Don't fail if a git repository is not available

[pirelenito]

I think having a default behavior that simply returns a default value as the hash and version is a more user-friendly option.

This would of-course, be a major version bump.

[pirelenito]

We can probably put this behavior behind a flag.

[bebraw]

Maybe failing hard isn't bad if you can let the user know how to fix the situation (i.e., set up git).

[adriancmiranda]

How about check the existence of the .git directory? something like, run git init and go on...

[bebraw]

@adriancmiranda I know one way is to check for .git directory. Git itself might have something, though.

[adriancmiranda]

@bebraw I think the methods can bring empty results in this case.

Edit:

We can examine the contents of .git/objects too, or run git count-objects to check if objects exist in the repo.

[NKjoep]

I think it is very important to avoid failures when the branch has no commit or when an error occurs for other reasons.

My strategy would be to console.warn something so that the user knows what is happening and provide a fallback.

Something like no-version, no-commithash, no-branch to fill the void.

[pirelenito]

I'm not sure I fully agree @NKjoep, since it is also very dangerous to not fail.

As an example, I wouldn't want assets being pushed to production with the no-version values because of some problems with git.

I'm more inclined to do what @bebraw suggested and provide instructions to a user on how to fix the problem (setup git).

[kaliatech]

An example use case where having the option to not fail with a missing .git is when using AWS CodePipeline. As of 2018-05, AWS CodePipeline doesn't clone the git repo, it simply downloads a zip. As a result, it's not possible to build there when using this plugin.

As would be expected, the resulting error is something like:

fatal: Not a git repository (or any parent up to mount point /codebuild/output)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set)

Agreed this is not really git-revision-webpack-plugin's problem, and I think CodePipeline's current implementation is wrong. But it is an example where having the option to not fail might be helpful.

[LinguineCode]

Thanks @kaliatech. I'm so glad I decided to google fatal: not a git repository (or any parent up to mount point /codebuild) before diving any deeper.

Any workarounds for us CodePipeline people? I didn't do any research yet. I've got a dev using https://github.com/nrwl which apparently depends on this project (unless someone else worded the above error the exact same way as you did) and I'm setting up CodePipeline to deploy the app.

[JefStat]

@seiyria a workaround for you

version: 0.2

env:
  parameter-store:
      buildsshkey_private: "buildsshkey_private"
phases:
  pre_build:
    commands:
      - echo "$buildsshkey_private" > ~/.ssh/id_rsa
      - chmod 600 ~/.ssh/id_rsa
      - git config --global url."git@github.com:".insteadOf "https://github.com/"
      - git init
      - git remote add origin "git@github.com:github/etc"
      - git fetch --depth=1
      - git checkout -f -t origin/master
      - git submodule init
      - git submodule update --recursive
      - npm -v
  build:
    commands:
      - npm i
      - npm run build

[kheftel]

Random addition: apparently heroku doesn't build within a git repo, even though the deploy command is literally git push heroku master. I'm using this plugin as described here, and indeed got the fatal: not a git repository error while deploying to heroku. Will look for workarounds later, but since I stumbled on this issue via googling, I figured I'd add my $.02.

[pirelenito]

Closing this issue since there hasn't been any activity in awhile, and I believe it is possible to work around it.