Do not create an initial release when the project is generated

[cjolowicz]

This PR contains the following changes:

• Use an initial version of 0.0.0 by default
• Do not report a bogus version number if Poetry exits with failure
• Do not apply a version tag unless there is a parent commit

Closes #334

Note that even with this PR, the Release workflow will fail if there is a parent commit which does not contain a Poetry-managed project. IMO this is best fixed upstream, by displaying a warning if the previous version number cannot be detected, instead of failing the workflow.

Discussion

These changes address several problems with the Release workflow when the generated project is initially pushed to GitHub. There are several different scenarios where this comes into play:

1. The initial commit contains the generated project.
2. The initial commit is empty, and the project is imported by merging a PR.
3. The initial commit is empty, and the project is imported using a second commit on master.
4. The parent commit of the import contains an existing project using Poetry.
5. The parent commit of the import contains an existing project using setuptools (or another packaging tool).

Scenario 1

Before the PR: The workflow would fail because of a missing parent commit. As the version number is already 0.1.0, and releases require a version bump, it would be impossible to release this version.

After the PR: The workflow will skip the tagging (producing only a TestPyPI release and draft GitHub release). Subsequent commits can create the initial release by bumping the version from 0.0.0 to 0.1.0.

Scenarios 2, 3, and 5

Before the PR: The initial import would result in an unintended release of 0.1.0, due to a detected version bump from could (from Poetry's error message) to 0.1.0.

After the PR: The workflow will fail because the parent commit does not define a version in pyproject.toml. Subsequent commits can create an initial release by bumping the version from 0.0.0 to 0.1.0.

Scenario 4

It depends if the existing project has seen a release. If so, and that version number was used when generating the project structure, there is no breakage before and after this PR. The workflow will succeed without creating a release.

Otherwise (i.e. if the project was unreleased):

Before this PR: If the default version number of 0.1.0 was used both in the existing project and in the generated project, the workflow would succeed without creating a release, but subsequent commits would be unable to release 0.1.0.

After this PR: The recommended method is to first reset the version to 0.0.0 before importing the project structure. This will avoid a bogus 0.0.0 release when importing the Release workflow.

Additional notes from the commit messages

• Set initial version to 0.0.0

Releases are triggered by version bumps, so projects should not be
generated with version 0.1.0, the initial version recommended by the
Semantic Versioning standard. Starting at 0.0.0 allows any non-zero
version to be used as the initial version.

• Fail Release workflow when poetry version exits with failure

The Release workflow detects a bogus previous version if the parent commit does
not contain a pyproject.toml file with a tool.poetry.version field.

Poetry is run as the first job in a pipeline, so its non-zero exit code is not
reported back to the action. Poetry writes its error message to stdout, which
results in a reported version "could" (second word of the error message).

Fix this by running the command via bash -o pipefail -c. Note that it is not
possible to use set -o pipefail inside the version command. The GitHub
Action (salsify/action-detect-and-tag-new-version) always uses /bin/sh, which
happens to be dash in Ubuntu. The dash shell does not support pipefail.

• Do not tag in Release workflow unless there is a parent commit