Simply semantic-release config and increase flexibilty

ideas.md

The current plugin system aims to make every step of semantic-release customizeable. There is a lot of overhead to this though.

Idea:

1. Remove verifyConditions.
2. Hardcode one check that implements every CI server out there. (Mappings for each service are trivial to add, much like in https://github.com/auchenberg/volkswagen)
3. Add an option to surpass this check.

With this it would "just work™" on any CI server. If there is custom behavior required this can simply be run before the semantic-release command: e.g. verify-unicorns && semantic-release pre && npm publish && semantic-release post. This custom check could also set an env var read by semantic-release, so the internal CI check is surpassed.

Offers same flexibility, less to no config.

Idea:

Remove verifyRelease.

The verification can be performed with custom scripts outside of semantic-release: semantic-release pre && verify-release && npm publish && semantic-release post

Idea:

Implement a post step that works for GitHub, GitLab and BitBucket, and automatically performs the right thing based on auth exposed, and repository URL. If this needs to be customized: semantic-release pre && npm publish && custom-release-notes If this needs to be left out: semantic-release pre && npm publish

Idea:

Implement a commit analyzer that works for all commit message styles available in conventional-changelog: https://github.com/ajoslin/conventional-changelog/tree/master/conventions Defaults to Angular, chosing another style means passing one config flag. Passing a custom parser works like it's working right now.

Metadata

If semantic-release could make extracted metadata (commits, version details, etc.) available in the environment or in a temp file, then the custom scripts could simply pick it up again without the need to extract or parse them again.

Though I prefer code over configuration, I also agree with @boennemann's statement about avoiding additional files. My projects typically have 6 hidden config files just to support the various tools already in use (jscs, jshint, git, etc.). It's become a little burdensome. The practice of leveraging package.json is perfect.

I agree that verify-conditions needs to be significantly changed. At one point I was using snap-ci, and I ended up just disabling the CI verification step so I could move forward with my work. A simple package that just verifies the existence of the required env keys should be sufficient. We shouldn't otherwise care what CI they're on.

I'm a little concerned about the post step idea. My concern is that once a developer needs to support another SCM platform besides those listed, they'll need to write functionality that will eventually resemble semantic-release, such as commit extraction, parsing, authentication, posting to an API, etc. Eventually, they will have a standalone tool that does everything semantic-release's post task does, but only for one SCM. That person can't share that work with others. Each new SCM will require the duplication of much of the same code or workflow.

@boennemann I now have semantic-release-github-releaser and semantic-release-github-notifier ready (I believe as I haven't tried them in production.
As mentioned by stevemao in semantic-release/semantic-release#190 I think we can remove the analyzeCommits plugin end point.
Also, as noted by stevemao, we don't need a dedicated generatorNodes plugin end point either now that conventional-changelog has all the functionality we need (including presets that allow us to change the changelog output based on known formats)
That leaves verifyConditions, verifyRelease, and getLastRelease.
I don't think we need the first two. I need to look into the default verifyConditions plugin, but all that semantic-release needs is the GitHub token (which actually is only needed if you're using a GitHub release plugin), and the npm token (which is only needed if you're plublishing to the npm registry.). Requiring that semantic-release is running on a particular CI doesn't seem useful. Also, it should be up to the user to know how to check that semantic-release is only called once for their I system.
For verifyRelease I would expect that detecting breaking changes would be done in the pull request, not when you're finally ready to publish.
For example, I could setup my build to detect breaking changes for pull requests, and if a breaking change is detected, verify that the pull request commit message has the BREAKING CHANGE tag in it. If not, fail the build.
Therefore I think we can get rid of both verifyConditions and verifyRelease.
That just leaves getLastRelease, and a refactor of semantic-release to resolve many of the outstanding issues.