kopia lustrzana https://github.com/jupyterhub/repo2docker
commit
40f475f3c0
|
@ -0,0 +1,34 @@
|
||||||
|
name: Create a release on pypi.org
|
||||||
|
|
||||||
|
on:
|
||||||
|
push:
|
||||||
|
pull_request:
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
build-n-publish:
|
||||||
|
runs-on: ubuntu-18.04
|
||||||
|
steps:
|
||||||
|
- uses: actions/checkout@v2
|
||||||
|
|
||||||
|
- name: "Setup Python 3.8"
|
||||||
|
uses: actions/setup-python@v2
|
||||||
|
with:
|
||||||
|
python-version: "3.8"
|
||||||
|
|
||||||
|
- name: "Install dependencies"
|
||||||
|
run: |
|
||||||
|
pip install --upgrade setuptools pip
|
||||||
|
pip install --upgrade -r dev-requirements.txt
|
||||||
|
pip freeze
|
||||||
|
|
||||||
|
- name: "Build distribution archives"
|
||||||
|
run: |
|
||||||
|
python setup.py sdist bdist_wheel
|
||||||
|
|
||||||
|
# This step is only run when a new tag is pushed
|
||||||
|
# all previous steps always run in order to exercise them
|
||||||
|
- name: Publish distribution to PyPI
|
||||||
|
if: startsWith(github.ref, 'refs/tags')
|
||||||
|
uses: pypa/gh-action-pypi-publish@master
|
||||||
|
with:
|
||||||
|
password: ${{ secrets.PYPI_API_TOKEN }}
|
46
.travis.yml
46
.travis.yml
|
@ -1,46 +0,0 @@
|
||||||
dist: xenial
|
|
||||||
os: linux
|
|
||||||
language: python
|
|
||||||
cache: pip
|
|
||||||
services:
|
|
||||||
- docker
|
|
||||||
python:
|
|
||||||
- 3.8
|
|
||||||
install:
|
|
||||||
# Make a wheel and install it to test to catch possible
|
|
||||||
# issues with releases
|
|
||||||
- pip install --upgrade setuptools pip
|
|
||||||
- pip install -r dev-requirements.txt
|
|
||||||
- python setup.py bdist_wheel
|
|
||||||
- pip install dist/*.whl
|
|
||||||
- pip freeze
|
|
||||||
script:
|
|
||||||
- |
|
|
||||||
# run autoformat
|
|
||||||
if [[ "$REPO_TYPE" == "lint" ]]; then
|
|
||||||
pre-commit run --all-files
|
|
||||||
fi
|
|
||||||
after_success:
|
|
||||||
- pip install codecov
|
|
||||||
- pushd tests && codecov && popd
|
|
||||||
|
|
||||||
after_failure:
|
|
||||||
- |
|
|
||||||
# point to auto-lint-fix
|
|
||||||
echo "You can install pre-commit hooks to automatically run formatting"
|
|
||||||
echo "on each commit with:"
|
|
||||||
echo " pre-commit install"
|
|
||||||
echo "or you can run by hand on staged files with"
|
|
||||||
echo " pre-commit run"
|
|
||||||
echo "or after-the-fact on already committed files with"
|
|
||||||
echo " pre-commit run --all-files"
|
|
||||||
|
|
||||||
deploy:
|
|
||||||
provider: pypi
|
|
||||||
username: mybinderteam
|
|
||||||
distributions: sdist bdist_wheel
|
|
||||||
on:
|
|
||||||
tags: true
|
|
||||||
repo: jupyterhub/repo2docker
|
|
||||||
password:
|
|
||||||
secure: ZkJTcI6fVkh2yRB0UVwSPVvGtfade7sQDZ6BjQR5bHRZuBLFq4/nxmn88BIPc6uYEHB6hxxfr9RbyP7ZnyUVUoTiyRfDM8kQe0RvFUVxRj7brZZFMYt6OTMiPUgWvyDqYIdVx+D5qgFgLxnQtUiZ0iqvPgQ+9Jn5SxZuuovrARpaTavlmKo4Vw63Ks/3zV61YeehvELFxU2Ibjy5ujMo/R119KZ7G3Z1w0IyJyVZQ9WaG1VXLO1LjFifpCcjMawaTJ9TmD5BOdF4IAIlP2QlB9N+v2xxuEGy7Mc9FwAH6M8kNqmjhe/ayj83vEMmlkxhE66unqiFJkSXzH1Rh8ythOy9s9qiDgeZeW/rYYLrzVNl9aMHicidV4PKEzobwXS/u8c/wx0fsAMNPcHY+O/8+hFLwy4ZLHusNiyCjPv5sVOq7yM/EKCjkod71bzFOvnnCZ70S0pxrR1nwEKo3x8qaK7l9aw0raSgWyrp6VHzEI4zPfBvP+R2ZYCUqBBj7rrpEl2C02AMKEkTh7Xm5LpaAFCBBMUwTATg7hECmB232vO+C6CLED+ONmGost5jOgsGwIun6viM5eXhP1tCeC5XeAtYozo/9UUIc5yHZL/8YtnmfCxvSi7p6h4qgLDCviKTH3bJCsRjF1ktkTiWAT+wL/SywsRz5D9tjV4b70neM8I=
|
|
|
@ -23,4 +23,4 @@ There are a few other pages to highlight:
|
||||||
Its a good place to understand _why_ the team have made the decisions that they have along the way!
|
Its a good place to understand _why_ the team have made the decisions that they have along the way!
|
||||||
* We absolutely encourage discussion around refactoring, updating or extending repo2docker, but please make sure that you've understood this page before opening an issue to discuss the change you'd like to propose.
|
* We absolutely encourage discussion around refactoring, updating or extending repo2docker, but please make sure that you've understood this page before opening an issue to discuss the change you'd like to propose.
|
||||||
* [Common developer tasks and how-tos](https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html)
|
* [Common developer tasks and how-tos](https://repo2docker.readthedocs.io/en/latest/contributing/tasks.html)
|
||||||
* Some notes on running tests, buildpack dependencies, creating a release, updating the changelog and keeping the pip files up to date.
|
* Some notes on running tests, buildpack dependencies, creating a release, and keeping the pip files up to date.
|
||||||
|
|
|
@ -61,10 +61,11 @@ This outlines the process for getting changes to the repo2docker project merged.
|
||||||
3. Make edits in [your fork](https://help.github.com/en/articles/fork-a-repo) of the [repo2docker repository](https://github.com/jupyterhub/repo2docker).
|
3. Make edits in [your fork](https://help.github.com/en/articles/fork-a-repo) of the [repo2docker repository](https://github.com/jupyterhub/repo2docker).
|
||||||
4. Make a [pull request](https://help.github.com/en/articles/about-pull-requests).
|
4. Make a [pull request](https://help.github.com/en/articles/about-pull-requests).
|
||||||
Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidelines for both reviewers and contributors on merging a PR.
|
Read the [next section](#guidelines-to-getting-a-pull-request-merged) for guidelines for both reviewers and contributors on merging a PR.
|
||||||
5. Edit [the changelog](./../../changelog) by appending your feature / bug fix to the development version.
|
|
||||||
6. Wait for a community member to merge your changes.
|
6. Wait for a community member to merge your changes.
|
||||||
Remember that **someone else must merge your pull request**.
|
Remember that **someone else must merge your pull request**.
|
||||||
That goes for new contributors and long term maintainers alike.
|
That goes for new contributors and long term maintainers alike.
|
||||||
|
Because `master` is continuously deployed to mybinder.org it is essential
|
||||||
|
that `master` is always in a deployable state.
|
||||||
7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html)
|
7. (optional) Deploy a new version of repo2docker to mybinder.org by [following these steps](http://mybinder-sre.readthedocs.io/en/latest/deployment/how.html)
|
||||||
|
|
||||||
## Guidelines to getting a Pull Request merged
|
## Guidelines to getting a Pull Request merged
|
||||||
|
@ -84,7 +85,6 @@ These are not hard rules to be enforced by 🚓 but they are suggestions written
|
||||||
This makes it easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" <deployed-revision>..` and your PR easier to review.
|
This makes it easier to find all changes since the last deployment `git log --merges --pretty=format:"%h %<(10,trunc)%an %<(15)%ar %s" <deployed-revision>..` and your PR easier to review.
|
||||||
* **Make it clear when your PR is ready for review.**
|
* **Make it clear when your PR is ready for review.**
|
||||||
Prefix the title of your pull request (PR) with `[MRG]` if the contribution is complete and should be subjected to a detailed review.
|
Prefix the title of your pull request (PR) with `[MRG]` if the contribution is complete and should be subjected to a detailed review.
|
||||||
* **Enter your changes into the [changelog](./../../changelog)** in `docs/source/changelog.rst`.
|
|
||||||
* **Use commit messages to describe _why_ you are proposing the changes you are proposing.**
|
* **Use commit messages to describe _why_ you are proposing the changes you are proposing.**
|
||||||
* **Try to not rush changes** (the definition of rush depends on how big your changes are).
|
* **Try to not rush changes** (the definition of rush depends on how big your changes are).
|
||||||
Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests.
|
Remember that everyone in the repo2docker team is a volunteer and we can not (nor would we want to) control their time or interests.
|
||||||
|
|
|
@ -113,41 +113,35 @@ added and why. If you fix a bug or add new functionality consider adding a new
|
||||||
test to prevent the bug from coming back/the feature breaking in the future.
|
test to prevent the bug from coming back/the feature breaking in the future.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Creating a Release
|
## Creating a Release
|
||||||
|
|
||||||
We try to make a release of repo2docker every few months if possible.
|
We make a release of whatever is on `master` every month. We use "calendar versioning".
|
||||||
|
Monthly releases give users a predictable pattern for when releases are going to
|
||||||
We follow [semantic versioning](https://semver.org/).
|
happen and prevents locking up improvements for fixes for long periods of time.
|
||||||
|
|
||||||
A new release will automatically be created when a new git tag is created
|
A new release will automatically be created when a new git tag is created
|
||||||
and pushed to the repository (using
|
and pushed to the repository.
|
||||||
[Travis CI](https://github.com/jupyterhub/repo2docker/blob/master/.travis.yml#L52)).
|
|
||||||
|
|
||||||
To create a new release, follow these steps:
|
To create a new release, follow these steps:
|
||||||
|
|
||||||
### Confirm that the changelog is ready
|
|
||||||
|
|
||||||
[The changelog](https://github.com/jupyterhub/repo2docker/blob/master/docs/source/changelog.rst)
|
|
||||||
should reflect all significant enhancements and fixes to repo2docker and
|
|
||||||
its documentation. In addition, ensure that the correct version is displayed
|
|
||||||
at the top, and create a new `dev` section if needed.
|
|
||||||
|
|
||||||
### Create a new tag and push it
|
### Create a new tag and push it
|
||||||
|
|
||||||
First, tag a new release locally:
|
First, tag a new release locally:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
V=0.7.0; git tag -am "release $V" $V
|
V=YYYY.MM.0; git tag -am "release $V" $V
|
||||||
```
|
```
|
||||||
|
|
||||||
|
> If you need to make a second (or third) release in a month increment the
|
||||||
|
> trailing 0 of the version to 1 (or 2).
|
||||||
|
|
||||||
Then push this change up to the master repository
|
Then push this change up to the master repository
|
||||||
|
|
||||||
```
|
```
|
||||||
git push origin --tags
|
git push origin --tags
|
||||||
```
|
```
|
||||||
|
|
||||||
Travis should automatically run the tests and, if they pass, create a
|
GitHub Actions should create a
|
||||||
new release on the [repo2docker PyPI](https://pypi.org/project/jupyter-repo2docker/).
|
new release on the [repo2docker PyPI](https://pypi.org/project/jupyter-repo2docker/).
|
||||||
Once this has completed, make sure that the new version has been updated.
|
Once this has completed, make sure that the new version has been updated.
|
||||||
|
|
||||||
|
@ -159,51 +153,10 @@ release on the [GitHub repository releases page](https://github.com/jupyterhub/r
|
||||||
* Click "Draft a new release"
|
* Click "Draft a new release"
|
||||||
* Choose a tag version using the same tag you just created above
|
* Choose a tag version using the same tag you just created above
|
||||||
* The release name is simply the tag version
|
* The release name is simply the tag version
|
||||||
* The description is [a link to the Changelog](https://github.com/jupyterhub/repo2docker/blob/master/docs/source/changelog.rst),
|
|
||||||
ideally with an anchor to the latest release.
|
|
||||||
* Finally, click "Publish release"
|
* Finally, click "Publish release"
|
||||||
|
|
||||||
That's it!
|
That's it!
|
||||||
|
|
||||||
## Update the change log
|
|
||||||
|
|
||||||
To add your change to the change log, find the relevant Feature/Bug
|
|
||||||
fix/API change section for the next release near the top of the file;
|
|
||||||
then add one or two sentences as a new bullet point about your
|
|
||||||
changes. Include the pull request or issue number between square
|
|
||||||
brackets at the end.
|
|
||||||
|
|
||||||
Some details:
|
|
||||||
|
|
||||||
- versioning follows the x.y.z, major.minor.bugfix numbering
|
|
||||||
|
|
||||||
- bug fixes go into the next bugfix release. If there isn't any, you
|
|
||||||
can create a new section (see point below). Don't worry if you're
|
|
||||||
not sure about that, and think it should go into a next major or
|
|
||||||
minor release: an admin will let you know, or move the change later
|
|
||||||
to the appropriate section
|
|
||||||
|
|
||||||
- API changes should preferably go into the next major release, unless
|
|
||||||
they are backward compatible (for example, a deprecated function
|
|
||||||
keyword): then they can go into the next minor release. For release
|
|
||||||
with major release 0, non-backward compatible breaking changes are
|
|
||||||
also fine for the next minor release.
|
|
||||||
|
|
||||||
- new features should go into the next minor release.
|
|
||||||
|
|
||||||
- if there is no section for the appropriate release, you can add one:
|
|
||||||
|
|
||||||
follow the versioning scheme, by simply increasing the relevant
|
|
||||||
number for one of the major /minor/bugfix numbers, appropriate for
|
|
||||||
your change (see the above bullet points); add the release
|
|
||||||
section. Then add three subsections: new features, api changes, and
|
|
||||||
bug fixes. Leave out the sections that are not appropriate for the
|
|
||||||
newlye added release section.
|
|
||||||
|
|
||||||
Release candidate versions in the change log are only temporary, and
|
|
||||||
should be superseded by either a next release candidate, or the final
|
|
||||||
release for that version (bugfix version 0).
|
|
||||||
|
|
||||||
|
|
||||||
## Keeping the Pipfile and requirements files up to date
|
## Keeping the Pipfile and requirements files up to date
|
||||||
|
|
||||||
|
|
Ładowanie…
Reference in New Issue