standard-release/app

Language independent GitHub App for creating GitHub Releases, following the Conventional Commits and SemVer specifications

@standard-release/app

GitHub App for creating GitHub Releases, following the Conventional Commits and SemVer specifications

Please consider following this project's author, Charlike Mike Reagent, and ⭐ the project to show your ❤️ and support.

If you have any how-to kind of questions, please read the Contributing Guide and Code of Conduct documents.
For bugs reports and feature requests, please create an issue or ping @tunnckoCore at Twitter.

Project is semantically & automatically released on CircleCI by itself.

Table of Contents

• Install the App
• Usual Flow
• Alternative Flow
• See Also
• Contributing
  • Follow the Guidelines
  • Support the project
  • OPEN Open Source
  • Wonderful Contributors
• License

(TOC generated by verb using markdown-toc)

Install the App

Install this app on your preferred account: Standard Release GitHub App

Automatically publish GitHub releases, based on commits that follows Conventional Commits specification.
Pretty similar to the Semantic Release, but only an App.

back to top

Usual Flow

This app works best with it's @standard-release/cli for npm publishing, but is not limited to it!
So in case you want to combine both, follow this steps:

1. Install this App
2. Add your NPM_TOKEN env variable (needed for the CLI only) in your CI
3. Install @standard-release/cli (as devDependency for example)
4. Configure your CI to run standard-release only on master branch

Note: If you don't want automatic publish on continuous integration services, but want to run it locally whenever you want, then you should run standard-release --no-ci instead. See the cli docs for more info.

Alternative Flow

Otherwise, you still can use only the App and leave the npm publishing to another tool, for example semantic-release or standard-version, or Sindre's np. In this case the step is one: just install that app on your preferred account (your own or to some organization).

Basically, how this app works is pretty simple. It will listen to all CI jobs to finish successfully and then publish a GitHub Release. If some of the CI stuff fail, it won't do anything. The CI detection is based on a status name check, so it works for Travis, CircleCI, AppVeyor and others.

back to top

See Also

Some of these projects are used here or were inspiration for this one, others are just related. So, thanks for your existance!

• asia: Blazingly fast, magical and minimalist testing framework, for Today and… more | homepage
• detect-next-version: Calculates next version, based on given commit message and following… more | homepage
• docks: Extensible system for parsing and generating documentation. It just freaking… more | homepage
• git-commits-since: Get all commits since given period of time or by… more | homepage
• gitcommit: Lightweight and joyful git commit replacement. Conventional Commits compliant. | homepage
• parse-commit-message: Extensible parser for git commit messages following Conventional Commits Specification | homepage

back to top

Contributing

Follow the Guidelines

Please read the Contributing Guide and Code of Conduct documents for advices.
For bugs reports and feature requests, please create an issue or ping @tunnckoCore at Twitter.

Support the project

Become a Partner or Sponsor? 💵 Check the Partner, Sponsor or Omega-level tiers! 🎉 You can get your company logo, link & name on this file. It's also rendered on package page in npmjs.com and yarnpkg.com sites too! 🚀

Not financial support? Okey! Pull requests, stars and all kind of contributions are always welcome. ✨

OPEN Open Source

This project is following OPEN Open Source model

Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is built on collective efforts and it's not strongly guarded by its founders.

There are a few basic ground-rules for its contributors

1. Any significant modifications must be subject to a pull request to get feedback from other contributors.
2. Pull requests to get feedback are encouraged for any other trivial contributions, but are not required.
3. Contributors should attempt to adhere to the prevailing code-style and development workflow.

Wonderful Contributors

Thanks to the hard work of these wonderful people this project is alive! It follows the all-contributors specification.
Don't hesitate to add yourself to that list if you have made any contribution! ;) See how, here.

Charlike Mike Reagent 💻 📖 💬 👀 🔍

Consider showing your support to them. 💖

License

Copyright (c) 2017-present, Charlike Mike Reagent <[email protected]> & contributors.
Released under the Apache-2.0 License.

app's Issues

template: the `commit.heading` is empty when (v1.0.0 / first) major release is published

totally no sense

Don't rely on `context.github.repos.getTags` but on `new-release`'s `getVersions`

which will come in the next release of the new-release package.

Don't use NPM et al

Because there is collision, currently. Because before App finishes there is already new "latest" version.

For example, we commit fix type, CI ends in few seconds and publishes 2.0.3. App is a bit slower than the CI server so it understands that 2.0.3 is latest and bumps it to 2.0.4 and makes a tag and release for it instead of for 2.0.3

Add config option for required status checks

as per #10 and #10 (comment)

remove npmRegistry config

I don’t think you use that right now?

https://github.com/tunnckoCore/semantic-release-app/blob/5e2a40f6d232d6ff514a73ada957b6f15cf6366e/src/lib/config.js#L11

For the config: allow a list of regexes for "required" status checks

Just because Github don't give us a way to check if some status is required or not, there is only a "state" - pending, success, failure. And so, when for example you have required status check like WIP (the WIP Github App/Bot) then it is in pending state. But the thing that we currently can't have is.. what if the status is not required but still is in pending state?

I definitely don't want this new-release app to wait and require all statuses to pass and only then to be executed. Because some apps/services/checks/ci and etc can be very very slow and you may not care so much about them. You may only care about required ones.

https://twitter.com/tunnckoCore/status/1045823297135529984

Add commit body & footer after the bullets list

currently we only show the subject on the bullets list of changes.

It is a template thing and is configurable, but we should have good defaults.

template is here

https://github.com/tunnckoCore/semantic-release-app/blob/99fe28d3a4aeb04b20489fb42b47228dbd7c8705/src/lib/config.js#L13-L22

Monorepo support

Currently, I'm not sure if it works, but basically it should be easy to support it, because we are based on git-semver-tags which understands Lerna tags.

Use `pkg.version` instead of `pkg.dist-tags.latest`?

not sure.

simply config

There is a built in method context.config('your-config-file.yml', defaultOptions which will load configuration from the context repository at the path .github/your-config-file.yml: https://probot.github.io/api/latest/Context.html#config

I think you can simplify your code here quite a bit with it

https://github.com/tunnckoCore/semantic-release-app/blob/5e2a40f6d232d6ff514a73ada957b6f15cf6366e/src/lib/config.js#L31-L46

Support release template to link updated dependencies

Renovate has commit patter, on which we can parse and get the updated dependency and replace it with a link [@tunnckocore/pretty-config](link-to-resolved-homepage-of-that-package).

Should parse the locals.commit.subject to get the name update dependency <packageName> to

https://github.com/tunnckoCore/new-release-app/blob/c3d078798ba2bfb32a50b094188cfcb16f5fe7f7/src/index.js#L199-L203

let subject = locals.commit.subject
subject = subject.replace(/update dependency (.*) to/, 'https://ghub.io/$1')

locals.commit.subject = subject

Use `new-release@4`

The { getVersions } named export.

Providing getVersions(increment, { name: utils.getRepo(context).repo })

Reminder to not forget what is the trick with now.sh

Basically, the whole thing is that we base64 the PEM private key, then we decode it and assign it to PRIVATE_KEY env just when calling probot

now secret add semantic-private-key "$(cat *.private-key.pem | base64)"

Activate Renovate and add CircleCI job for auto releasing to Now.sh

So we can sleep well and don't care manually.

hint: add PRIVATE_KEY env to the org-global context

Should it wait all statuses to finish before release?

Or it is enough to wait only CI services to end.

Talking about that part

https://github.com/tunnckoCore/semantic-release-app/blob/0bbf1731584d69ab00d5bfc42241c9190e51ec39/src/index.js#L97-L106

I really i lost few hours today before i realized why it does not publish releases, just because of that ;d
Initially i was thinking about it and decide that it is good thing to wait everything to finish, but for example bitHound is slow, so publishing release may appear with delay of 5+ minutes in some cases.

/cc @gr2m

Publishes releases before CI ends

It wasn't that way before. That's strange.

Bug in rendering

the profiles.join(',') fucks for some reason.

It renders @tunnckoCore, [object Object], [object Object], [object Object], [object Object].

That not make any sense... but yea.

Reimplement from scratch - done (in ~100 lines as a whole)

Just because of the few updates and new packages that I published from locally.

• the yarn add detect-next-version@next (28 lines)
• which uses the new packages:
  • recommended-bump (~24 lines), and
  • @tunnckocore/package-json (~10 lines)

So, the implementation is near 50 lines, excluding the template and release rendering.

const getConfig = require('probot-config')
const detector = require('detect-next-version') // v3 (in the `next` tag)

module.exports = (robot) => {
  robot.on('push', (context) => {
    const settingsConfig = await getConfig(context, 'new-release.yml')
    const config = Object.assign({}, defaultConfig, settingsConfig)
    
    if (context.payload.ref !== `refs/heads/${config.defaultBranch}`) {
      return
    }

    let pkgData = null

    try {
      pkgData = await context.github.repos.getContent(context.repo({
        ref: context.payload.ref,
        path: 'package.json'
      }))
    } catch (err) {
      robot.log(err)
      return
    }

    // for ensurance, sometimes.. js can be bad boy.
    if (!pkgData) return

    const pkgJSON = JSON.parse(Buffer.from(pkgData.content, 'base64'))

    const pkgMeta = detector(pkgJSON.name, context.payload.head_commit)

    // If no need for bump, then exit.
    if (!pkgMeta.increment) {
      robot.log('No need for release publishing')
      return
    }

    // pkgMeta is like `{ lastVersion, nextVersion, pkg, increment }`
    robot.log(pkgMeta)

    // So, now:
    // 1. get release template from config (or default one)
    // 2. pass locals (eg. pkgMeta and more) to it
    // 3. render it
    // 4. pass it to context.github.createRelease

    // And we are done.
  })
}

Release template

Inspiration https://github.com/yarnpkg/yarn/releases, but group them.

Catch if getTags throws and fallback

If it throws (i believe), we should fallback currentVersion to '0.0.0' probably, so then we won't need to create initial release on every new package/repo

https://github.com/tunnckoCore/semantic-release-app/blob/2481b4d05e23c13ecf5832e0cf2f581981691311/src/index.js#L168-L178

Detect `[skip ci]` and `[ci skip]` insensitive

Just before the

https://github.com/tunnckoCore/new-release-app/blob/c3d078798ba2bfb32a50b094188cfcb16f5fe7f7/src/index.js#L47

Make a check if (/\[skip ci|ci skip\]/i.test(head.message)) return {}; kinda thing