Currently GIT_USER and GIT_EMAIL are not displays automatically and have to be added to environment variables and AWS tags manually like this:

    GIT_USER: ${git:user}
    GIT_EMAIL: ${git:email}

This variables should be added automatically.

This plugin seems incompatible with the serverless-mocha-plugin. Running sls invoke test with the git-variables plugin results in the following error:

ServerlessError: Invalid variable reference syntax for variable git:branch. You can only reference env vars, options, & files. You can check our docs for more info.

My custom section includes this:

custom:
  git: ${git:branch} - ${git:describe} - ${git:sha1}

And my functions reference it like so:

functions:
  graphql:
    name: ${self:provider.stage}-graphql
    description: GraphQL Handler (GET/POST /graphql) - ${self:custom.git}
    handler: functions/graphql.handler

Deploying works just fine. This only fails when trying to run my test suite.

We are using ${git:sha1} to version a cache, but it's sometimes empty. I couldn't track down any pattern to this, but for now we've just implemented our own variable in a JS file using child_process.execSync('git rev-parse HEAD').toString('utf-8').trim();, but wanted to report the issue.

Not sure if this is by design or not. But this is different than I was expecting, so if nothing else it might be worth mentioning this in the docs if it's by design.

I can see here that to compute isDirty the command being used is git diff --stat. That doesn't display staged changes. Ex:

$ git status
On branch master
nothing to commit, working tree clean
$ echo 'a change' > tmp
$ git diff --stat
 tmp | 1 +
 1 file changed, 1 insertion(+)
$ git add tmp
$ git diff --stat

I would love to be able to have a way to track if there are any changes between the working directory and the upstream repository state, staged or not. From my testing, it doesn't appear that any of the variables are sensitive to staged changes.

Perhaps this ticket isn't so much a bug with with git:isDirty but maybe more a feature request for a new variable git:hasStagedChanges. Either would work fine for my purposes.

Let me know what you think, and if there's the solution to this that you'd be open to merging and addresses my needs, I can write up a PR. Thanks a bunch for the plugin & happy holidays.

Expected Behavior

serverless deploy .... with version 3.2.0 of this plugin works as expected and has been for several months.

Actual Behavior with Version 3.3.0

Version 3.3.0 appears to break serverless deploy .... with the following error message:

Command failed: basename `git rev-parse --show-toplevel`
'basename' is not recognized as an internal or external command,
operable program or batch file.

Further Details

Executing the command git rev-parse --show-toplevel in the terminal works as well and produces the full current path.

The command basename in fact does not exist in my environment.

Environment

• Windows 10 Professional, 64 bit, english
• nodejs version 10.14.2
• npm version 6.7.0
• git: Git for Windows version 2.21.0
• serverless version 1.40.0
• Powershell 5.1.17134.590

Update: Workaround

To work around this issue, use version 3.2.0 of the plug-in.

When more then one tags points to a commit, deployment fails with following exception:

An error occurred: SomeLambdaFunction - 1 validation error detected: Value '{GIT_COMMIT_LONG=xxxxx, GIT_TAGS=prd-1.2.3,stg-1.2.3, GIT_COMMIT_SHORT=xxx}' at 'tags' failed to satisfy constraint: Map value must satisfy constraint: [Member must have length less than or equal to 256, Member must have length greater than or equal to 0, Member must satisfy regular expression pattern: ^([\p{L}\p{Z}\p{N}_.:/=+\-@]*)$] (Service: AWSLambdaInternal; Status Code: 400; Error Code: ValidationException; Request ID: xxx).

This isn't a source problem, but the latest version uploaded to npm is missing the lib directory. This means that require('serverless-plugin-git-variables') doesn't work (package.json main points to a path that doesn't exist, lib/index.js), so SLS cannot import the plugin anymore. It looks like src is available, but uses import, which doesn't work out of the box. So we do need the build tooling.

Thank you for your time, and for merging git:message! Sorry to add hassle to your day, that certainly isn't my intention.

Existing git:message returns the whole commit message, i.e. both subject and body. However, the body can sometimes be quite long and git:message used in Description of CloudFormation template can lead to error an error on deploy:

The CloudFormation template is invalid: Template format error: 'Description' length is greater than 1024.

Would be great to be able to use just the message subject alone, could be available as git:subject. Or even have git:messageSubject and git:messageBody to be able to get both parts of the message independently.

The plugin should hook in early enough to allow serverless print to display the actual ENV conditions that would be deployed.

I regularly use characters in my commit messages which are invalid for AWS tags. The result is a cloud-side error like this:

1 validation error detected: Value '' failed to satisfy constraint: Member must satisfy regular expression pattern: [\p{L}\p{Z}\p{N}_.:/=+-@]*

The problem is that the time to error is quite long, so I would prefer a client-side error. I can see how this could be problematic as people might use git variables in places other than AWS tags and don't care about this validation - or might need other validations.

Maybe this is not even the right place to add the validation, and a generic validation plugin might be more suitable. E.g.

plugins:
  validation:
    awsTags:
      - ${git:messageSubject}
    awsApiStageName:
      - ${git:repository}
      - ${git:branch}

Platform: macOS Mojave 10.14.6 (18G87)
Git Version: git version 2.20.1 (Apple Git-117)
Node Version: v8.15.0

Steps to reproduce:

$ git clone https://github.com/jacob-meacham/serverless-plugin-git-variables.git
$ yarn install
$ yarn test
yarn run v1.16.0
$ nyc ava
(node:51688) Warning: process.on(SIGPROF) is reserved while debugging

  6 passed
  1 failed

  Rejects on bad git command
  /private/var/folders/8b/6yg0sc5j2xs1smk_32f62cp40000gn/T/tmp-51690ZckSmyP17oo6/test/index.spec.js:48

  Threw unexpected exception:

  Error {
    cmd: 'git log -1 --pretty=%B',
    code: 128,
    killed: false,
    signal: null,
    message: `Command failed: git log -1 --pretty=%B␊
    fatal: not a git repository (or any of the parent directories): .git␊
    `,
  }

  Test.<anonymous> (test/index.spec.js:48:11)
  Test._ava2.default.serial [as fn] (test/index.spec.js:44:1)
  processEmit [as emit] (node_modules/nyc/node_modules/signal-exit/index.js:146:32)
  processEmit [as emit] (node_modules/nyc/node_modules/signal-exit/index.js:146:32)
----------|----------|----------|----------|----------|----------------|
File      |  % Stmts | % Branch |  % Funcs |  % Lines |Uncovered Lines |
----------|----------|----------|----------|----------|----------------|
All files |    98.59 |    89.29 |      100 |    98.59 |                |
 index.js |    98.59 |    89.29 |      100 |    98.59 |            117 |
----------|----------|----------|----------|----------|----------------|
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

I found this related commit so the test was changed on purpose:
961ec07

I would guess the error message which is matched against in the test varies depending on some combination of git, platform, node version.

The readme mentions the GIT_IS_DIRTY environment variable, but not ${git:isDirty}

Sometimes we deploy the same commit to different environments using tags, and git:describeLight seems to pick up the wrong tag from time to time.

git itself provides a way to filter the tag returned by using --match <pattern>, I wonder if it is possible to support this through custom.gitDescribeMatchPattern: <pattern>?

This should be very useful feature to know who have something deployed for audit reasons.
E.g. our use case is to distinguish if given service was deployed via Jenkins or if it was deployed by some human and who?
We have micro-service architecture with a lot of stacks and lambda functions and many small distributed teams so for us it would be extremely helpful if GIT_USER and GIT_EMAIL would be exported by default.
I think this feature would be useful for the most of the people and if somebody don't want to populate his email or password, he could always use gitVariablesEnvWhitelist and or gitVariablesTagsWhitelist feature to hide this info.

I'm getting on occasion erratic failures like the following:

  Error --------------------------------------------------

  Command failed: git describe --always --tags


     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Issues:        forum.serverless.com

  Your Environment Information ---------------------------
     Operating System:          win32
     Node Version:              10.15.0
     Serverless Version:        1.49.0
     Enterprise Plugin Version: 1.3.6
     Platform SDK Version:      2.1.0

I suspect that this may be due to the 1 second timeout on the git command. I feel that's a bit short (maybe 10 seconds would be more reasonable). Running the command git describe --always --tags directly always works fine.

Does this actually require Node 7 as specified in package.json?

As it stands I can't install in my project that uses node 6 without modification...

sls deploy worked fine manually with ${git:user}

but we're trying to automate it, and we are using an ssh key instead of a user for git clone etc

however, when there is no user, the deploy process dies completely with

Error:
Cannot resolve serverless.yaml: Variables resolution errored with:
  - Cannot resolve variable at "functions.resampler.tags.LastDeployedBy": Error: Command failed: git config user.name

    at ChildProcess.exithandler (node:child_process:422:12)
    at ChildProcess.emit (node:events:517:28)
    at ChildProcess.emit (node:domain:489:12)
    at maybeClose (node:internal/child_process:1098:16)
    at Socket.<anonymous> (node:internal/child_process:450:11)
    at Socket.emit (node:events:517:28)
    at Socket.emit (node:domain:489:12)
    at Pipe.<anonymous> (node:net:351:12)

Exited with code exit status 1

maybe it could put an empty string or 'null' or something for the git user in this scenario? or at least not kill the deploy?

Running "serverless" from node_modules
Framework Core: 3.25.1 (local) 3.1.0 (global)
Plugin: 6.2.2
SDK: 4.3.2

Thanks for creating this useful plugin!

I tried it out yesterday by installing the node module globally and adding it to my serverless.yml.

Then I did run into the following error:

$ serverless --help

  Error --------------------------------------------------

     Cannot find module 'babel-runtime/core-js/promise'

     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.

  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues

     Please report this error. We think it might be a bug.

  Your Environment Information -----------------------------
     OS:                 linux
     Node Version:       7.9.0
     Serverless Version: 1.6.1

After installing 'babel-runtime' globally, too, everything worked as expected.

I guess that 'babel-runtime' should not be a module that is necessary for just using serverless-plugin-git-variables, right?

My lambda function is deployed with env var GIT_BRANCH with value HEAD
and with env var GIT_BRANCH with value source.

This happens when it's deployed using https://seed.run/

Any ideas how can this be avoided? Thanks

With the latest serverless i've got:

Serverless: Deprecation warning: Approached unrecognized configuration variable sources: "git".
        From a next major this will be communicated with a thrown error.
        Set "variablesResolutionMode: 20210326" in your service config, to adapt to new behavior now
        More Info: https://www.serverless.com/framework/docs/deprecations/#NEW_VARIABLES_RESOLVER

I've tried importing serverless-plugin-git-variables in my Serverless project I see it has a dependency on babel-runtime. Last publish is 3 years ago and I get a warning that it depends on a now-deprecated version of core-js.

Current version of babel runtime is @babel/runtime. Would be great to use it and get rid of the core-js warning... Would be even nicer to have the plugin not need it at all, since installing it brought me 51 dependent packages to node_modules.

Hi, I just had some struggling around your pluging, it's still not working for my environment actualy for no reason. But I made some workaround and replace your _exec function:

async function _exec(cmd, options = {
  timeout: 1000
}) {
  return new Promise((resolve, reject) => {
    _child_process.default.exec(cmd, options, (err, stdout) => {
      if (err) {
        reject(err);
      } else {
        resolve(stdout.trim());
      }
    });
  });
}

with this one:

async function _exec(cmd, options = {
  timeout: 1000
}) {
    return _child_process.default.execSync(cmd, { ...options, encoding: 'utf-8' }).trimEnd();
}

and now it's works for me.

I could create MR but I think it's a bit dirty. Just In case you would like to investigate.

My environment:

• Windows 10
• gitbash
• node(v14.16.1)

I've been looking for way to use my git tags as serverless variables and your project seemed like the perfect match. Although I'm still not able to get tag to show up, only the git sha.

I'm using ${git:describe} and I think it was expected that it showed the tag, at least according to the latest release note:

git describe now uses --always, so if there are not tags it returns a hash instead of failing (Thanks to @e-e-e)

In my experience to display the tag you had to add the --tags after --always in order to show the current tag you're on. I thought maybe it was macOS specific, however I tried on Ubuntu with the same result.

Would it be possible to add the --tags to the git describe command? I could obviously do a PR but I want to make sure I'm not mistaken first.

Perhaps a nice feature is to also add the url of the primary remote?

Hey @jacob-meacham, Thanks for merging my PR!

I had another thought, that I may not get around to PR'n for a bit. But it would like be a good idea to refactor out all git CLI commands in favor of using something like NodeGit directly.

This will likely mean that the plugin would then work across OSs.

For a while I'd thought this was because I was doing simultaneous deployments, but recently it has happened when only running a single deployment.

$ sls deploy

  Error --------------------------------------------------

  Command failed: git write-tree
fatal: Unable to create '/Users/peter/workspace/my-serverless-app/.git/index.lock': File exists.

A second run without any intervention on my part (I did not look for or delete an index.lock file) succeeded, which suggests to me that there is actually some kind of race condition inside this plugin?

Hi getting the following error.

  Type Error ---------------------------------------------
 
     this.getValueFromSource(...).then is not a function
 
     For debugging logs, run again after setting the "SLS_DEBUG=*" environment variable.
 
  Get Support --------------------------------------------
     Docs:          docs.serverless.com
     Bugs:          github.com/serverless/serverless/issues
     Forums:        forum.serverless.com
     Chat:          gitter.im/serverless/serverless
 
  Your Environment Information -----------------------------
     OS:                 darwin
     Node Version:       6.10.3
     Serverless Version: 1.13.2

Looks like _getValueFromGitSync is expected to return a promise but isn't.

yarn add -D serverless-plugin-git-variables
yarn add v1.9.4
warning package.json: No license field
$ npm i use-yarn && use-yarn || ( npm install --save-dev --no-scripts --no-save use-yarn && use-yarn )
[email protected] /Users/vadorequest/dev/student-loan-simulator-serverless/aws/loan-advisor
└─┬ [email protected] 
  └── [email protected] 

npm WARN [email protected] requires a peer of ajv@^6.0.0 but none was installed.
npm WARN [email protected] No repository field.
npm WARN [email protected] No license field.
warning [email protected]: No license field
[1/4] 🔍  Resolving packages...
[2/4] 🚚  Fetching packages...
error [email protected]: The engine "node" is incompatible with this module. Expected version ">=7.0".
error Found incompatible module
info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command.

I'm running node 6 and can't upgrade, no way to make it work for me then?

Hi 👋 , Serverless Framework core team here!

We're working on the v3 beta version right now. The v3 will include a redesigned CLI output:

You can try the v3 beta with: npm i serverless@pre-3

I had a quick look at the code of this plugin and it seems like you don't log anything to the CLI output. So I don't think there is anything to change in this plugin.

Let me know if I'm wrong. I'd be happy to help in any way if needed.

Feel free to close this issue if there is nothing to do indeed.

In any case, here is some more information on new plugin API we have added, in case you are curious:

• Video introduction (Youtube)
• Documentation of the new API

Any feedback is appreciated on all that!