caitp / grunt-bower-release Goto Github PK

When I try using this I get the above error. It is creating a cwd directory and i'm guessing it's trying to create src directory which already exists.

It does create the dist-push directory with the contents of the endpoint just fine.

My bowerRelease config:

  bowerRelease: {
      options: {
        main: 'lib.tmpl.min.js'
      },
      prod: {
        options: {
          endpoint: 'https://some.domain.com:8443/lib.git',
          stageDir: 'dist-push'
        },
        files: {
          cwd: 'dist',
          src: ['lib.js', 'lib.min.js', 'lib.tmpl.min.js', 'templates.js', 'bower.json']
        }
  }

After running the code was never pushed.

When run with -v I'd get the following:

git push origin  0.3.15
Username for 'https://git.com/repo.git': kkruit
Password for 'https://[email protected]/repo.git': 
error: src refspec undefined does not match any.
error: failed to push some refs to 'https://git.com/repo.git'

Turns out it is actaully calling:

git push origin undefined 0.3.15

Because "branchName" is undefined.

Suggested Resolution:
Docs needs branchName defined as an option.

git.js endpoint needs to not put branchName in args if it's undefined

I'm planning on making a PR which is a simple fix but I would really like to tighten the testing net to include this which means a test for the endpoint is needed.

I've cloned the repository and just run 'grunt test' unfortunately I've got a message saying:

Warning: 2/24 assertions failed (179ms) Use --force to continue.

Aborted due to warnings.

Interestingly, I can see the same message in Travis CI. So, the problem is persistent and is not related to my local environment.

I have the following options in bowerRelease in Gruntfile.js
Not sure how to fix this.

options: {
                    main: '*.{css,js,eot,svg,woff,tff}',
                    endpoint: myRepoEndpoint,
                    branchName: 'master',
                    packageName: 'robo-ui-bower',
                    stageDir: 'stage/'
                },
                files: [
                    {
                        expand: true,
                        cwd: 'dist/compiled/',
                        src: ['**/*']
                    }
                ]

git checkout -B master
Writing /code/robo-ui/stage/bower.json...OK
git add /code/robo-ui/stage/RoboGlyphs.ttf
fatal: Unable to create '/code/robo-ui/stage/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.
git add /code/robo-ui/stage/RoboGlyphs.woff
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
modified: robo-ui.min.css

Often, you might want to overwrite an existing version. For example, you might want to have a pre-release snapshot dependency (e.g. 1.0.0-SNAPSHOT). A snapshot version indicates that it might change over a course of time.

For example, two people - Alice and Bob - are working on a Sprint that will result in releasing version 1.0.0. While writing code though they put a version number of 1.0.0-SNAPSHOT. If Alice finishes her user story first, her 1.0.0-SNAPSHOT goes into a dependency repository. When Bob finishes his story later on, the snapshot version will be updated and will include both Alice's and Bob's code.

Now, the challenge with Bower is that it uses Git tags as versions. If you push a tag 1.0.0-SNAPSHOT, all subsequent pushes of the same tag will fail - and new code will not land in Git.

One way of doing solving the problem is to delete a git tag before pushing it. The problem with this approach though, if you do 'bower update' or 'bower install' it will not know about a newly released dependency, as it has the same tag name.

Fortunately, there is a solution - one can suffix tags with '+[some unique ID]'. That unique ID can be a commit SHA or a timestamp.

In this case, if you have a specific dependency version expression in your bower.json, e.g.

"dependencies": {
  "your-dependency": "1.0.0-SNAPSHOT"
}

It will easily pick a dependency whose Git tag is '1.0.0-SNAPSHOT+2014', see node-semver for a reference. However, there is a minor issue here. If you simply push a new Git tag (e.g. '1.0.0-SNAPSHOT+2014', '1.0.0-SNAPSHOT+2015'), every time you're invoking grunt-bower-release, Bower will not pick it.

However, there is still a workaround for that - grunt-bower-release can list all tags and delete the tags which correspond to the current version before pushing a new tag. In this case, 'bower update/install' will successfully pick an overwritten dependency without having to clean its cache.

I have verified that behaviour experimentally, however, I am still yet to submit a pull request with the described functionality.

This seems to be a bug that can mislead users, because they will think that a release has been successful, while no code has been pushed to Git.

Steps to reproduce

1. Add an intentionally wrong Git endpoint to Gruntfile.js
2. Run grunt bowerInstall

Expected Behaviour

1. The bower task must fail
2. It must notify that the Git endpoint is not available

Actual Behaviour

1. The task succeeds
2. It says Done, without errors.

Additional Information

You can clearly see that the released has failed if you run grunt bowerRelease --v which say something like:

fatal: Not a git repository (or any of the parent directories): .git

Done, without errors.

Solution

Unless there is already a patch for that, I'm going to submit a pull request shortly.

I think this can be done better, so I'll put in a few minutes this week to take care of that

When I don't enter a dest and I use cwd it's placing all files in {stageDir}/{files:cwd}/{files:src} instead of {stageDir}/{files:src}.

This should be doable, there's no good reason why grunt is required for this...

The problem with it is that the grunt code ends up in the coverage reports, and this kind of sucks.

These are kind of important to have, so yeah...

I just realized that the source repository's bower dependencies may be totally unrelated to release dependencies, IE they may likely contain components for a documentation app. This is certainly the case for my angular-drop project, so this needs to be done differently.

I think it should be okay to say "extendDependencies: true" in order to use the current behaviour, but by default it should really not do this. I suppose it's a breaking change, but there are so few users of this package it doesn't really matter!

Tasks directory should be for shipped code only, the mock endpoint code ought to live in the test directory.

After the last change I made, I'm not terribly confident in how this will work! test suite asap!