Git Product home page Git Product logo

chandler's Introduction

IRB.send :easter_egg, :dancing

Spinning Ruby logo

💬 Writing

I write about Ruby and related programming topics at mattbrictson.com/blog. Here are some articles I’ve posted recently:

🧑‍💻 Projects

I’m currently working on:

mighty_test – Minitest is the standard testing library for Ruby projects, but it lacks the DX polish that developers have come to expect from modern testing tools. My mighty_test gem gives Minitest a modern CLI with common-sense features like color output, fail-fast, CI integration, and interactive watch mode.

nextgen – I regularly update a Rails app generator with recommendations based on my latest Rails consulting work. Nextgen embraces the fact that every project has different requirements, and offers dozens of interactive options, including Vite for apps that need robust TS/React frontends.

tomo – This is my take on a modern alternative to Capistrano for deploying Rails apps. It focuses on a friendly developer experience: familiar SSH concepts, an intuitive CLI, well-documented extension points, and helpful error messages. I use tomo to deploy many of my side projects.


Other Ruby open source projects that I’ve built and continue to support:

  • bundleup is a CLI for Gemfile upgrades. It’s a bit like yarn upgrade-interactive, but for Bundler.
  • pgcli-rails plugs into Rails apps to replace the default database console with the more full-featured pgcli.
  • gem is a GitHub template for building and maintaining gems.

🪴 Maintenance

I also serve as a core contributor and maintainer for the following Ruby projects:

chandler's People

Contributors

appden avatar deivid-rodriguez avatar dependabot-support avatar dependabot[bot] avatar dotmpe avatar mattbrictson avatar orta avatar simenb avatar zearin avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

chandler's Issues

Ignore missing versions

When running chandler push on a changelog, there might be some versions that I have tags for which aren't present in the changelog. It would be nice if I could have chandler ignore the missing versions in the changelog and just push what it can. Currently I get an error, like:

/Users/jonathan/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/chandler-0.1.2/lib/chandler/changelog.rb:35:in `block in fetch': Couldn’t find 0.2.1 in CHANGELOG.md (Chandler::Changelog::NoMatchingVersion)

Auto-uploading binaries

I wish chandler had a way to auto-upload binaries when creating a new releases on GitHub.

The behavior could be something like, for each tag that doesn't already have a release invoke a user-specified build command (please don't tie this to rake specifically) and upload the user-specified files as "binaries" to GitHub under that release.

Some kind of "force" mode making it possible to back-fill old releases would be a bonus.

source code requires UTF-8

seems it fails to run on C locale because source code is not US-ASCII vs '

og.rb:39: invalid multibyte char (US-ASCII)
/home/travis/.rvm/gems/ruby-2.4.1/gems/chandler-0.7.0/lib/chandler/changelog.rb:39: invalid multibyte char (US-ASCII)
/home/travis/.rvm/gems/ruby-2.4.1/gems/chandler-0.7.0/lib/chandler/changelog.rb:39: syntax error, unexpected $end, expecting keyword_end
        raise NoMatchingVersion, "Couldn’t find #{tag} in #{path}"
                                          ^
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /home/travis/.rvm/gems/ruby-2.4.1/gems/chandler-0.7.0/lib/chandler/configuration.rb:1:in `<top (required)>'
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from bin/ci/tag-update.rb:8:in `<main>'

customizable release title

currently the github "tag title" is filled with just "version"

however, i used to fill there also release date:

https://github.com/eventum/scm/releases/tag/v3.1.2 2016-09-06, Version 3.1.2

now chandler will overwrite that with 3.1.2 once ran

perhaps set the tag title as the line present in changelog file itself:

2016-09-06, Version [3.1.2]

but care should be taken with the []-s (stripped because the link itself is not included): #27

Warn before overwriting existing releases

By default, chandler push uploads the release notes for all tags, overwriting any existing releases that are already published on GitHub. This can result in data loss if there are notes in GitHub that aren't in the changelog file.

Chandler should somehow prevent this mistake, perhaps with an opt-in command line switch, or an "are you sure?" prompt.

(Optional) replace full GH issue links with just #NUMBER

To have valid links in CHANGELOG.md to GitHub issues (and PRs) it is required to have full URL in markdown [#1](https://github.com/mattbrictson/chandler/issues/1). In GH release notes it is enough to have just #1. While full link renders fine in GH release notes in a situation you have new release notifications in an (old shool) text form (e.g. with Sibbell which in addition wraps the links) the output is clumsy.

instead of just:

  • Auto drop repository after release - #37
  • Rename "promote" operation to "release" - #50

It would be nice to (on demand) replace full links to own issues with just numbers during export.

Allow configuration of chandler through a dotfile

I would like to configure chandler using a raketask however I don't like putting configuration in my raketask. This stems mainly from liking to use a standard rakefile across all of my projects. It would be nice if the CLI or raketask option could be configured via a dotfile so that is abstracts the configuration away from the task to be done.

Nothing happens?

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?

Tag-Prefix does not work as expected

I have a changelog with following content:

## [1.0](https://github.wdf.sap.corp/iot/nGrinderTools/tree/ms/1.0) (2017-04-05)
## [ms/1.0](https://github.wdf.sap.corp/iot/nGrinderTools/tree/ms/1.0) (2017-04-05)

Furthermore I have following tag:

  • ms/1.0

I would expect that at least one of these changelog entries would be pushed to the release notes. Nevertheless I get following message:

chandler push --tag-prefix ms/ --dry-run
Skip ms/ (no ms/ entry in CHANGELOG.md)```

More gentle error on not existing tag

Currently Chandler fails with:

/home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/changelog.rb:38:in `fetch': undefined method `version_number' for nil:NilClass (NoMethodError)
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/commands/push.rb:60:in `changelog_version_and_notes_for_tag'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/commands/push.rb:43:in `block in each_tag_with_version_and_notes'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/commands/push.rb:42:in `each'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/commands/push.rb:42:in `each_tag_with_version_and_notes'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/commands/push.rb:29:in `call'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/lib/chandler/cli.rb:22:in `run'
	from /home/foo/.gem/ruby/gems/chandler-0.7.0/exe/chandler:4:in `<top (required)>'
	from /home/foo/bin/chandler:22:in `load'
	from /home/foo/bin/chandler:22:in `<main>'
(...)

in the station a requested single tag is not found. There could be nicer dedicated error message for that.

Workflow question

Can you help clarify the workflow?

  1. create a new tag for the release
  2. create a new branch off of develop for the task
  3. run github_changelog_generator and commit
  4. run chandler which will populate the Release Notes from the CHANGELOG
  5. creates final PR of the sprint, merging the CHANGELOG in.

Unknown: how/when does the changelog get into the release, as it is generated after the tag?

Gentle Version Handling

We would like to use your tool, but we have a continous delivery pipeline in place. This pipeline enforces the build only once principle and creates versions which are extended by an timestamp + commitId.

Our versions look like: 0.1.0-20170405101014+6175ca3224ba086e1b22b7923ba3282aa9d4db01

The used validation regex (Gem::Version::VERSION_PATTERN => ^[0-9]+(.[0-9a-zA-Z]+)*$\ )
does not allow the used "-" and "+" symbols.

Is it possible to allow - and + within the version?

on release notes update are version dates overwritten to current date

I've applied chandler on the project and noticed that all the dates are now overwritten with the date of update.

Is there a chance to fix it?

Current text says:

[username] released this 2 days ago · [XY] commits to master since this release

The problem is, that I introduced it to the project couple ears old (also with releases couple years old), but it seems these were released only couple days back.

I'd appreciate a chance to take the release date from the relese notes (as we have it there anyway).

allow specify version to update

currently there doesn't seem to be a way to update only single release

as for example, issues like #24 - i'd like to correct the release notes, so for that would need to run the update only for single release (git tag)

ps: also, it's not really possible to see what is going to be posted to github api. i would like to see actual text it parsed out. dry-run option just shows versions list it parsed out.

Allow other formats

Is it out of scope for this project to allow other formats of the CHANGELOG file e.g yaml?

Edit: if not, I'd love to contribute.

Don't strip all leading whitespace from release notes

Stripping all leading whitespace can cause an issue with certain markdown formatting. Consider a bullet list like this:

  * One
  * Two
  * Three

Stripping leading whitespace results in something that doesn't format as intended:

* One
  * Two
  * Three

usage in travis-ci

I'd love to automate this process for my project.
Would you mind documenting a way to sync changelog in travis-ci build? I'd love to do this once I tag my project. Any chance for that?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.