This page contains starter kit information, which represent templates, code and configuration to help you get started quickly with continuous integration (CI) best practices described in this overall guide. Please see categories and links below for details.
This section contains links to sample actions, templates and configurations that demonstrate CI systems in practice on various platforms using different development languages.
A complete, deployment-ready Python 3 application that's bundled into a reusable template repository for quick implementation.
This product demonstrates a GitHub-based strategy of end-to-end CI automation using modern Python tooling to demonstrate publishing on release.
- Build automation using GitHub, Docker, GitHub Actions and PyPi
- Compile, tag and release, and publish to the Python Package Index (PyPi)
- Modern PEP 517/518 compliant tooling using declarative TOML-based configurations inside a
pyproject.toml
file.
Starter Kit:
To leverage this template, make sure to do the following:
- Discuss with your development team continuous integration best practices and seek consensus on a workflow to build, publish and release software.
- Create a new repository by one of the following methods:
Requirement
• Sandbox strategy: Two separate accounts must be created on (1) Test PyPi and (2) PyPi. We'll name values identically and switch them later when everything works.
• Admin rights are necessary to set upGitHub Secrets
.
- Setup account credentials:
- Test PyPi website
- Navigate to
Account Settings
->API tokens
and press the buttonAdd API Token
. Name your tokenPYPI_API_TOKEN
and generate it. - Copy the value and retain this Test PyPi token to use in
GitHub Secrets
.
- Navigate to
- PyPi website
- Navigate to
Account Settings
->API tokens
and press the buttonAdd API Token
. Name your tokenPYPI_API_TOKEN
and generate it. - Copy the value and retain this PyPi token to use later.
- Navigate to
- GitHub Secrets (use the Test PyPi token here initially) in your newly created repository
- In the repository, select the
Settings
tab and navigate toSecurity
:Secrets and variables
-->Actions
and press the buttonNew repository secret
. - Name your secret
PYPI_API_TOKEN
and paste the value from Test PyPi. (Later, this value will be replaced with the actual PyPi token to enable public release.)
- In the repository, select the
- Test PyPi website
Shortcut
Already skilled with Python Setuptools build system? You may selectively apply files from the starter kit to your own project using details below.
- Choose a unique name for your Python 3 module. The name shouldn't duplicate any of the currently published modules in PyPi.
- Move code into place
- New project? Rename the existing
slim_sample_project
directory to your unique module name. Renamehello_world.py
to reflect your application and start developing.- Don't remove versioning system files (
version.py
andversion_tooling.py
) that support build tooling. - You'll have to keep the local module import of
version_tooling
to take advantage of build version automation. - Consider organizing code into smaller, encapsulated component files that may be imported from the
api
directory.
- Don't remove versioning system files (
- Existing code? Move the directory containing your Python 3 code into the new project and rename it to match your unique module name.
- Copy versioning system files (
version.py
andversion_tooling.py
) from theslim_sample_project
that support build tooling. - Add the local module import of
version_tooling
to your Python 3 top-level file or entry-point script.
- Copy versioning system files (
- New project? Rename the existing
Shortcut
Lines requiring code updates are commented with the keywordMODIFY
.
Documentation requiring updates are marked with the keywordINSERT
.
- Apply project settings and customizations
- Update
pyproject.toml
to update build system dependencies- Edit the
write_to
variable to point to the directory containing your Python 3 code.
- Edit the
- Update
setup.cfg
to specify build system configurations- Edit the metadata keywords to set appropriate keyword values to apply to your project.
- Set
name
to match your unique module name. - Modify
console_scripts
to point at your entry-point:- If your module launches from a command-line, define an executable inside your module:
executable-name = my_package.module:function
. - Set the value as empty if there is no entry-point.
- If your module launches from a command-line, define an executable inside your module:
- Update URLs for your project.
- Replace
NASA-AMMOS/slim-starterkit-python
with the project/repo_name for your cloned project.
- Replace
- Update
author
,author_email
,description
andkeywords
to reflect your project details
- Set
- Edit the metadata keywords to set appropriate keyword values to apply to your project.
- Update documentation to reflect details about your new project
- Suggested updates for
CODE_OF_CONDUCT.md
,CONTRIBUTING.md
andREADME.md
are marked by the keywordINSERT
and explained in detail within markdown.
- Suggested updates for
- Update
Alert
Unique development configurations may adversely impact testing on local workstations. Testing should be conducted with a supported python.org release or virtual container as used on GitHub .
- Build locally to test the configuration
The application will build, install and deploy from a local command line when all configurations are properly set.- Install local tooling and requirements
- Clean and build and clean again after module builds successfully
Information
To validate the module, we test on the Test PyPi sandbox by default. Then, to release on the official PyPi, a minor configuration change is required. All previous steps must be complete.
- Build on GitHub
A release kicks off a build and release process in GitHub Actions.- Test publication on Test PyPi
- Update the version number in the
version.py
file. - Kick off a build by releasing your product using the same version.
- When the product builds successfully, proceed to step ii. Otherwise, revisit earlier steps and check for errors or other invalid settings.
- Update the version number in the
- Release to PyPi (simple configuration changes point at the release server)
- Update
PYPI_API_TOKEN
to point at PyPi in GitHub Secrets in your newly created repository- In the repository, select the
Settings
tab and navigate toSecurity
:Secrets and variables
-->Actions
. - Recalling the PyPi token previously saved in step 3(ii): In
Repository secrets
, edit thePYPI_API_TOKEN
and paste the saved PyPi token value to update it.
- In the repository, select the
- Change the
python-publish.yml
configuration to remove Test PyPi coordinates- Remove '
--repository testpypi
' from the one-line publish command to read:twine upload --verbose dist/*.whl dist/*.zip
- Remove '
- Update the version number in the
version.py
file. - Kick off a build by releasing your product using the same version.
- Update
- Test publication on Test PyPi
This starter kit produces several deliverables deployed for distribution:
- GitHub
- PyPi
- Fully documented site with project links
- Source distribution (with release hashes):
- Built Python 3 distribution:
This section contains links to sample actions, templates, and configuration for ensuring the basic integrity of patches.
This GitHub Action provides an automated check for ensuring developers have a "signed-off" commit when contributing to a given GitHub repository.
Starter Kit:
- GitHub App to install onto your GitHub repo
To leverage this template, make sure to do the following:
- Talk with your team about leveraging this GitHub action, and seek wide agreement before you adopt
- Log into GitHub.com
- Click the above GitHub App starter kit link
- Click "Install" in the top-right hand corner of the page
- Follow the prompts to select the organizations and repositories you'd like to install this app
- Verify the installation by navigating to your given repository's "Settings" page, and confirming the app appears in the "Integrations -> Applications" left-hand menu
This tool helps prevent unauthorized sensitive secrets and credentials from being committed to a Git repository. It scans commits and looks for regular patterns of credential information, and through the mechanism of a client-side Git hook, it alerts the developer to any unintended commits. Further, it also supports the ability to scan a repository's history of commits for any unauthorized commit activity. It is by default optimized for scanning for Amazon Web Services (AWS) credentials, but can be customized to look for custom credential string patterns.
Starter Kit:
- Git Hook to install locally on your machine
To leverage this template, make sure to do the following:
- Navigate to the git-secrets installation section, and follow the instructions per your platform
- Run
git secrets --install
within your chosen repository- You should received a confirmation such as the below:
✓ Installed commit-msg hook to .git/hooks/commit-msg ✓ Installed pre-commit hook to .git/hooks/pre-commit ✓ Installed prepare-commit-msg hook to .git/hooks/prepare-commit-msg
- Register a secrets/credentials provider that helps the tool find specific types of credential patterns, e.g. AWS via
git secrets --register-aws
- Automation should be set up to scan for new commits, but it's a good idea to scan the history of commits starting out:
git secrets --scan-history
- If you receive no output, that means the tool found now problematic commits.