Giter VIP home page Giter VIP logo

clparse's Introduction

clparse

clparse is a command line tool for parsing CHANGELOG files that use the Keep A Changelog format. The CHANGELOG file can be Markdown, JSON, or YAML format and can also be output into any of those formats once parsed.

Installation

Homebrew (macOS)

$ brew install marcaddeo/clsuite/clparse

Linux

$ curl -LO https://github.com/marcaddeo/clparse/releases/download/0.9.1/clparse-0.9.1-x86_64-unknown-linux-musl.tar.gz
$ tar xzvf clparse-0.9.1-x86_64-unknown-linux-musl.tar.gz
$ sudo mv clparse /usr/local/bin/clparse

Cargo

$ cargo install clparse

Usage

clparse 0.9.1
Marc Addeo <[email protected]>
A command line tool for parsing CHANGELOG.md files that use the Keep A Changelog format.

USAGE:
    clparse [FLAGS] [OPTIONS] <FILE>

FLAGS:
    -h, --help       Prints help information
    -n, --no-wrap    Disable wrapping of change entries of a release. By default, change entries are wrapped at 80
                     characters.
    -V, --version    Prints version information

OPTIONS:
    -f, --format <format>          Sets the output format of the parsed CHANGELOG [default: markdown] [possible values:
                                   json, yaml, yml, markdown, md]
    -s, --separator <separator>    Sets the separator character used between version and date in a release heading
                                   [default: -]
    -w, --wrap-at <wrap-at>        Specify how many characters to wrap change entries at [default: 80]

ARGS:
    <FILE>    The CHANGELOG file to parse. This should be either a Markdown, JSON, or Yaml representation of a
              changelog. Use '-' to read from stdin.

Examples

By default, clparse will parse the input file, and output the changelog in markdown format.

$ clparse CHANGELOG.md
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]
### Fixed
- Fix a bug that caused undefined behavior

## [1.0.0] - 2019-06-20
### Added
- Add a cool new feature

### Changed
- Change something that was notable

## [0.0.1] - 2019-05-31
### Added
- Add the initial features

[Unreleased]: https://github.com/example/example/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/example/example/compare/v0.0.1...v1.0.0
[0.0.1]: https://github.com/example/example/releases/tag/v0.0.1

We can transform the markdown into a format that can be easily used in scripts:

$ clparse -f json CHANGELOG.md
{
  "title": "Changelog",
  "description": "All notable changes to this project will be documented in this file.\n\nThe format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),\nand this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).\n\n",
  "releases": [
    {
      "version": null,
      "link": "https://github.com/example/example/compare/v1.0.0...HEAD",
      "date": null,
      "changes": [
        {
          "fixed": "Fix a bug that caused undefined behavior"
        }
      ],
      "yanked": false
    },
    {
      "version": "1.0.0",
      "link": "https://github.com/example/example/compare/v0.0.1...v1.0.0",
      "date": "2019-06-20",
      "changes": [
        {
          "added": "Add a cool new feature"
        },
        {
          "changed": "Change something that was notable"
        }
      ],
      "yanked": false
    },
    {
      "version": "0.0.1",
      "link": "https://github.com/example/example/releases/tag/v0.0.1",
      "date": "2019-05-31",
      "changes": [
        {
          "added": "Add the initial features"
        }
      ],
      "yanked": false
    }
  ]
}

clparse can also parse JSON and YAML representations of the changelog:

$ clparse CHANGELOG.json
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]
### Fixed
- Fix a bug that caused undefined behavior

## [1.0.0] - 2019-06-20
### Added
- Add a cool new feature

### Changed
- Change something that was notable

## [0.0.1] - 2019-05-31
### Added
- Add the initial features

[Unreleased]: https://github.com/example/example/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/example/example/compare/v0.0.1...v1.0.0
[0.0.1]: https://github.com/example/example/releases/tag/v0.0.1

And finally, we can read from stdin by passing - as the FILE argument:

$ clparse -f json CHANGELOG.md | clparse -
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]
### Fixed
- Fix a bug that caused undefined behavior

## [1.0.0] - 2019-06-20
### Added
- Add a cool new feature

### Changed
- Change something that was notable

## [0.0.1] - 2019-05-31
### Added
- Add the initial features

[Unreleased]: https://github.com/example/example/compare/v1.0.0...HEAD
[1.0.0]: https://github.com/example/example/compare/v0.0.1...v1.0.0
[0.0.1]: https://github.com/example/example/releases/tag/v0.0.1

clparse's People

Contributors

koppor avatar marcaddeo avatar

Stargazers

avatar avatar avatar avatar avatar avatar avatar

Watchers

avatar avatar

Forkers

koppor x42h napalmpapalam

clparse's Issues

Yanked release and version comparison links slightly wrong

When you yank a release the next release is still using it in it's comparison link.. This is probably not ideal.

For example:

## [5.10.1] - 2020-01-02

## 5.10.0 - 2020-01-02 [YANKED]

## [5.9.5] - 2019-12-22

[5.10.1]: https://github.com/my/repo/compare/5.10.0...5.10.1

I think ideally this would go back to the previous release that is not yanked.

## [5.10.1] - 2020-01-02

## 5.10.0 - 2020-01-02 [YANKED]

## [5.9.5] - 2019-12-22

[5.10.1]: https://github.com/my/repo/compare/5.9.5...5.10.1

Support non-SemVer and en dashes

When trying to parse https://github.com/JabRef/jabref/blob/v5.11/CHANGELOG.md, version is always null. I think, it could be because of the used en dash. There is an issue, because the official format might permit en dash (see olivierlacan/keep-a-changelog#497; linked from nbbrd/heylogs#140 (comment)).

    {
      "version": null,
      "link": "https://github.com/JabRef/jabref/compare/v5.10...v5.11",
      "date": null,

If en dash support is "difficult" to implement, maybe this tool coud parse the github compare link to get the version out of that link?

(General background: I was recommended clparse at NiclasvanEyk/keepac#20 (comment))

Non-Semver should be recognized if no "--separator" is provided

Follow-up to #22. Minor issue.

clparse --format=json --separator=–

works great

clparse --format=json

always outputs null as version.

I wonder whether it was possible that version is non-null, but date is null (because the separator is not known)

This might be too complex. Feel free to close the issue. My usecase works with --separator=–. Just wanted to share some ideas for "know-less" tooling :).

Cargo install fails with "Could not find `__rt` in `quote`"

This looks like a neat tool. Thank you for implementing it!

When I ran cargo install clparse, it failed with the following error:

error[E0433]: failed to resolve: could not find `__rt` in `quote`
   --> /home/emk/.cargo/registry/src/github.com-1ecc6299db9ec823/err-derive-0.1.6/src/lib.rs:145:63
    |
145 | fn display_body(s: &synstructure::Structure) -> Option<quote::__rt::TokenStream> {
    |                                                               ^^^^ could not find `__rt` in `quote`

Change entries should wrap at 80 caharacters

When rendering the Changelog data as Markdown, the individual change entries should wrap at 80 characters.

Current'y we're preserving line breaks, and indentation, to handle such a scenario. Not sure if that current code would conflict with wrapping at 80 chars.

However, new changes added with cl don't have any wrapping on them since they're just yaml. So we need to figure out the best way to wrap the lines. Probably best to just strip all newlines out of change entries, and wrap them manually.

Yanked releases are not working properly

Couple issues I noticed:

  1. Yank releases don't show up with clparse CHANGELOG.md
  2. (This may be aggregate-changes related only) When a release is yanked, it still renders it's link somehow.

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.