This allows us to see our CI checks running before we merge. Now that we have CI set up in our project from our last post it is good practice to switch to GitHub Flow where we work on branches and raise pull requests to merge into master. Next in our is-number project directory we want to make a new branch based off master which adds a new GitHub Actions workflow file. ![]() Now our token is available for use in our GitHub Actions workflows. ![]() We will give our secret a name of PYPI_PASSWORD and paste in the token that PyPI provided us. If we head to our repo on GitHub and then the Settings > Secrets page we should see a “New Repository Secret” button. We are going to add this token to our is-number repo as a secret. This is the only time we will see this token so we need to make note if it now. Let’s create one called is-number-publish for our is-number package. If you click “Add API Token” you will be able to give your token a name and select the scope. If we log into PyPI and head to our “Account Settings” page we will find an “API Tokens” section part way down the page. API keys have limited access to PyPI and can only push new versions to one specific project, this means if the key were to get out someone can only do limited damage with it. We could do the same thing in our GitHub Actions workflow, however it is better practice to use a more constrained API key instead. In part 3 we used twine to upload our package which prompted us for our username and password. The first thing we are going to need to do is allow GitHub Actions to publish packages to PyPI on our behalf. Conda Forge will then automatically detect this new version and update our feedstock over there, so we don’t need to worry about that. To automate our releases we are going to use GitHub Actions to build and publish our package to PyPI. In this post we are going to automate these steps so when we create our tag and push to GitHub everything else is done for us. ![]() In parts two and three of this series we tagged version 0.0.1 of our is-number package and manually distributed it to PyPI and Conda Forge. This is typically done by creating a tag on a specific commit in git and then packaging up the code at that commit and releasing it to the world. At some point the maintainers of the project will decide to release a new version. In many open source projects new code is added to a main branch via Pull Requests. Continuous DeliveryĬontinuous delivery (CD) is an automated process where software is packaged and delivered to the end user. In this post we will cover automatically packaging and releasing our project when a new git tag is pushed to GitHub. If you haven’t read the previous parts you may want to go back and check those out. 6 minute read #python, #github, #tutorialĬreating an open source Python project from scratch series.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |