Add mechanical releases

[jaraco]

In GitLab by @jaraco on Sep 10, 2018, 02:34

Let's find a way to make tagged releases automatically released to PyPI.

[jaraco]

In GitLab by @warsaw on Sep 10, 2018, 17:29

+1 - can we do the same for importlib_resources too?

[jaraco]

In GitLab by @warsaw on Sep 10, 2018, 17:30

FWIW, I'm sure there's a way to do it with the pipelines and the .gitlab-ci.yaml file.

[jaraco]

In GitLab by @warsaw on Sep 11, 2018, 16:42

@jaraco I'm going to assign this one to you. Whatever works here should also work for importlib_resources.

[jaraco]

In GitLab by @warsaw on Sep 11, 2018, 16:42

assigned to @jaraco

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 20:55

mentioned in commit 8f308ac

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 20:55

closed via commit 8f308ac

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 20:58

The latest commit solves this issue. I have to push to master to verify that the credentials work there, as they don't in other branches. But I do expect this job to either succeed and release 0.2b1 to PyPI or to be rejected because 0.2b1 isn't a valid version for PyPI.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:04

reopened

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:07

That job failed again due to non-existent credentials, despite me having set the credentials.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:30

In this job we can see that the variables aren't set:

release runtests: commands[1] | python -m twine upload dist/*
Uploading distributions to https://upload.pypi.org/legacy/
Enter your username: EOFError: EOF when reading a line

Even though they absolutely are. Oh, wait, I used the wrong var names (TRAVIS_* instead of TWINE_*).

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:35

After setting TWINE_USERNAME and TWINE_PASSWORD, the output is different, but still failing. That looks like a bug in twine. Why isn't it honoring the TWINE_PASSWORD env var?

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:43

Master was not a protected branch, which probably explains why the variable isn't set. I suspect protected variables can only be used in protected branches. I've protected the master branch and given maintainers push and merge access to the master branch.

If this works, it's an annoying aspect about GitLab - you can't have one feature (protecting secret variables) without enforcing other protections (disallowing force-push to master). Those two facets are apparently linked.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:44

Well, that wasn't it.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:46

Since it seems that the TWINE_USERNAME is being honored, I've removed the protected status on the TWINE_PASSWORD to see if that works.

{{image.png}}

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:47

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:53

That did the trick and now importlib_metadata 0.2 is now in PyPI. I had expected that would upload 0.2b2, but I forget that the version is stored in importlib_metadata/version.txt and not in the tags... so it doesn't matter what you tag, you get what's in version.txt. We'll have to adjust the other pending efforts to target 0.3.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:53

closed

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 21:56

I've returned the master branch to being unprotected, since that didn't seem implicated in the issue.

I am now doubly-uneasy about the presence of my password being exposed in the repo. Presumably anybody now could submit a pull request to the project and have it echo $TWINE_PASSWORD and have the password for my PyPI repos.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:00

The docs do say that protected variables once set will be set for subsequent pipelines. Since I was retrying a previously-run pipeline, perhaps the protected variables only are included for protected branches for subsequent pipelines. I'll configure the repo accordingly and retry.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:00

reopened

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:04

Since I've already released 0.2, I've gone ahead and tagged that commit, which created this new pipeline. I did that after once again setting the master as a protected branch and setting the TWINE_PASSWORD as a protected variable.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:08

Nope. Still didn't work. GitLab's docs are wrong.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:08

closed

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:24

Oh, I think I know now what's going on. Since the release only runs on tags, it's only "protected tags" that are relevant when allowing for "protected variables". In other words, "protected branches" are irrelevant. I'm going to mark all tags as protected and remove the protections once again from the master branch.

[jaraco]

In GitLab by @jaraco on Sep 11, 2018, 22:35

Good news! That worked. So if other projects like importlib_resources wish for this functionality, it should be as simple as porting 8f308ac and 559f6c3 to it and setting all tags to be protected.

[jaraco]

In GitLab by @warsaw on Sep 11, 2018, 23:20

@jaraco Thanks! I'll retarget the milestone issues and MR's, update version.txt and update the changelog.rst. Do you mind porting this to importlib_resources?

[jaraco]

In GitLab by @jaraco on Sep 12, 2018, 01:03

mentioned in merge request !9

[jaraco]

In GitLab by @jaraco on Sep 12, 2018, 01:09

mentioned in merge request importlib_resources!67