Skip to content
This repository has been archived by the owner on May 16, 2021. It is now read-only.

Nothing happens? #3

Closed
jhalterman opened this issue Feb 3, 2016 · 8 comments · Fixed by #4
Closed

Nothing happens? #3

jhalterman opened this issue Feb 3, 2016 · 8 comments · Fixed by #4
Labels
Milestone

Comments

@jhalterman
Copy link

Trying out chandler on a project and basically, nothing happens. I get no output, even with --debug, even when running against chandler's CHANGELOG itself. Any ideas?

@mattbrictson
Copy link
Owner

Yikes! Perhaps you've tried this already, but if you are in the Chandler project and run this command, what happens? Here is what I see:

$ bundle exec chandler push --dry-run
Push v0.1.0… ✔ 0.004s
Push v0.1.1… ✔ 0.000s
Push v0.1.2… ✔ 0.000s

Also, could you provide your ruby and bundle versions to help me troubleshoot?

$ ruby -v
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]
$ bundle -v
Bundler version 1.11.2

Thanks!

@jhalterman
Copy link
Author

From the chandler dir:

$ bundle exec chandler push --dry-run
Push v0.1.0… ✔ 0.005s
Push v0.1.1… ✔ 0.000s
Push v0.1.2… ✔ 0.000s
$ ruby -v
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14]
$ bundle -v
Bundler version 1.11.2

@mattbrictson
Copy link
Owner

OK, good! So what happens when you try to do push --dry-run within your own project?

@jhalterman
Copy link
Author

No output...

@mattbrictson
Copy link
Owner

Chandler first scans your Git repository for tags. For each tag that represents a version number (e.g. v1.0.0), it finds the matching release notes in the CHANGELOG and uploads them to GitHub. My hunch is that your repository doesn't have any version number tags (e.g. v1.0.0). In this case there is nothing for Chandler to do.

You can check by running:

git tag -l

I should probably fix Chandler so that it prints something like "No version tags found" in this case, rather than silently exiting.

Is my hunch correct?

@jhalterman
Copy link
Author

Right now I'm running it on https://github.com/jhalterman/typetools just to try it out. The tags there are:

$ git tag -l
typetools-0.2.1
typetools-0.3.0
typetools-0.3.1
typetools-0.4.0
typetools-0.4.1
typetools-0.4.2
typetools-0.4.3
typetools-0.4.4

So, I'm guessing the formatting of the tag names is the problem. These tags are created automatically by Maven whenever I do a release - so at least in Java-land, this release tag format is pretty common.

@mattbrictson
Copy link
Owner

Ah, interesting.

How do you think Chandler should handle this? I could change the tag matching behavior so that any tag ending in a version number is used. However I think that might be too broad and may match things that aren't version tags.

Or I could add a --tag-prefix=typetools- command line option that would tell Chandler how to find the right tags. This would accommodate your use case without changing the default behavior.

Any preference or other suggestions?

Thanks for the bug report, btw!

@jhalterman
Copy link
Author

The first thing that comes to mind for me is to accept a format. So a format like: typetools-v{version} could be used to match a hypothetical version typetools-v1.0, where 1.0 would be extracted as the version. The format syntax doesn't really matter to me, but it might be a bit more flexible than doing prefix or suffix matching.

Edit: I am guessing a --tag-prefix option would work for most use cases though, including mine.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants