7 Commits
Author SHA1 Message Date
ohemorangeandBrad Warren 658b7b9d47 Add VIRTUALENV_NO_DOWNLOAD=1 to all calls to virtualenv (#6690)
This will immediately address the breakage reported in #6682 and tracked at #6685. Virtualenv downloads the latest pip, which causes issues, so tell virtualenv to not download the latest pip.

I added the flag preemptively to other files as well, they're in separate commits so it will be easy to revert any spots we don't want.

I've confirmed that this fixes the issue on a machine that fails with the version of certbot-auto currently in master: recent version of virtualenv, python 2.7.

* Update changelog

* Use an environment variable instead of a flag for compatibility with old versions

* Run build.py
2019-01-24 10:03:52 -08:00
ohemorangeandBrad Warren 1cdcc15e64 Pin all dependency installation in the release script (#6584) (#6602)
Fixes #6584.

* Pin all dependency installation in the release script

* also use pip_install.py to install pytest
2019-01-02 10:08:08 -08:00
ohemorangeandBrad Warren daa77b5023 During the release, reset local-oldest-requirements.txts that might have been changed during development. (#6547)
* During the release, reset local-oldest-requirements.txts that might have been changed during development.

* only modify the file if it exists

* no need to specifically add certbot-compatibility-test because it doesn't have the file anyway

* Use double quotes instead of single

* escape dots and brackets

* Escape and quote correctly
2018-12-03 16:42:52 -08:00
Brad WarrenandGitHub 37d4b983c8 Don't use pytest.ini during the release. (#6550)
Currently the release script in master fails for a few reasons. First, it's trying to use --numprocesses which comes from a pytest plugin that we're not installing in the release script. Second, many new warnings are raised when we're not using pinned versions of our dependencies.

I'm not sure I agree, but one could argue that we should fix these issues and use the file during the release. I'm particularly hesitant for us to do this when it comes to warnings. We currently do not pin our dependencies in the release script. Do we really want to stop the release because a new package was released and is warning about something? One could argue we do because these warnings may be visible to the user, but they very rarely are and I think this makes the release process much too painful.

I especially do not think we should block the release on this now as we are not up to date on the warnings raised by the latest versions of our packages so there is a lot to work through.

* Don't use pytest.ini during the release.

* State that pytest.ini isn't used in release script.
2018-11-30 17:40:55 -08:00
ohemorangeandGitHub f65cb070b3 Automation for changelog changes during release (#6489)
* Automation for changelog changes during release

* Update changelog during release before modifying version numbers

* don't link to the GitHub repo

* no need to sign the commit bumping version numbers

* simplify tail call
2018-11-26 17:48:59 -05:00
Brad Warrenandohemorange 251355cade Add better error handling around release signatures (#6353)
* Better error handling around sig after offline-sig

* Add error handling around first sig with git.

* Don't fail if offline-sig fails.
2018-09-11 15:44:26 -07:00
Brad Warrenandohemorange e178bbfdf5 Release script improvements (#6337)
* Add error checking and automatic logging.

* Ignore release dir and logs

* Don't always require PGP card and fix script cmd.

* keep track of default GPG key

* Add PGP card sanity check after offline signature

* fix typo

* I'm tired of pressing y.

* Automate running tools/offline-sigrequest.sh.

* Update comment and make output more readable.
2018-09-05 14:10:05 -07:00