cjolowicz/cookiecutter-hypermodern-python

Release workflow fails on code import if TEST_PYPI_TOKEN is unset

Opened this issue · 11 comments

cjolowicz commented

The initial GitHub upload of a generated project can result in a broken build, because the Release workflow will attempt to upload the package to TestPyPI, and the TEST_PYPI_TOKEN may not have been set yet.

There are two things we can do about this:

  • Document that tokens should be set up before pushing.
  • Make the TestPyPI upload conditional on TEST_PYPI_TOKEN being set.

Related questions:

  • Which other external services can be set up before pushing, and which should be?
  • Which other CI steps can be conditional on services being set up, and which should be?
staticdev commented

@cjolowicz there is this new manual triggers that could put the workflow/commit in a pending state if TEST_PYPI_TOKEN or even PYPI_TOKEN and CODECOV_TOKEN are not set. One could skip it or insert manually these tokens so that the workflow completes successfully.

cjolowicz commented

That's an interesting idea. But AFAIU manual triggers apply to the entire workflow, not an individual step. They also don't support additional conditions. Or am I missing something here?

staticdev commented

I also didn't dig deep into that.. I am used to manual steps in jenkins and gitlab-ci, so I thought it would be the same in GA. But I see you found a simple and clever solution.

cjolowicz commented

Unfortunately steps cannot be conditional on the presence of a secret, see #512. We might still document the correct flow to set up a repository without creating a failed workflow run on import.

cjolowicz commented

A workaround would be to copy the secret to an environment variable first, see actions/runner#520 (comment). As pointed out later in that thread, this could result in leaking the secret in debug runs, so maybe this is not an option.

staticdev commented

@cjolowicz that depends on the threat model we are using. But for most cases, test pypi credentials shouldn't be critical and it is not that it IS leaking, but can possibly leak. Seems safe to me.

pauleveritt commented

Small addendum... the PyPA workflow action guidelines recommend naming it PYPI_API_TOKEN with API in there.

Also, I don't see a mention in the docs about adding the pypi- prefix to the secret?

cjolowicz commented

Hi @pauleveritt thanks for chiming in here! I'm hesitant to change the secret name to PYPI_API_TOKEN, as it would potentially break people who keep their existing projects up-to-date with the template, using tools such as cruft. I agree that using the same name as the PyPA recommendation reduces friction for people who already follow it in their projects. On the other hand, I wouldn't see the name as part of the "normative part" of the guide.

As for the pypi- prefix, I'm not sure I understand. Isn't that just part of the API token as displayed by PyPI?

pauleveritt commented

Reasonable point and thanks for pointing me at cruft. Ignore the pypi- part, this was me making a mistake with getting the token.

Thanks so much for the work on this cookiecutter and especially the docs and blog post series.

cjolowicz commented

You're welcome!

cjolowicz commented

A workaround would be to copy the secret to an environment variable first, see actions/runner#520 (comment). As pointed out later in that thread, this could result in leaking the secret in debug runs, so maybe this is not an option.

See also https://github.community/t/if-expression-with-context-variable/16558