Hi everyone, I recently had the chance to integrate a CI workflow into TXT to HTML Converter project. I'll talk about it below.
What was the Set up Process Like?
Setting up the workflow for my project was very simple. I followed the steps from the tutorial posted by GitHub and basically created a workflow to test my project. GitHub created template for me, and the directories to store the YAML file in.
What Does my Workflow Look Like?
After the YAML file was created, I continued to follow GitHub's tutorial. It was very simple and direct, it told me how I can run my code on different versions of Python as well as different OSs. Here is the YAML file I used that tests with different Python versions and OSs.
# This workflow will install Python dependencies, run tests and lint with a single version of Python
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-python
name: Python application
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
permissions:
contents: read
jobs:
build:
runs-on: ${{ matrix.os }}
strategy:
matrix:
python-version: ["3.11", "3.12"]
os: [windows-latest]
steps:
- name: Checkout code
uses: actions/checkout@v2
- name: Set up Python ${{ matrix.python-version }}
uses: actions/setup-python@v2
with:
python-version: ${{ matrix.python-version }}
- name: Install dependencies
run: |
python -m pip install --upgrade pip
pip install ruff
- name: Lint with Ruff
run: |
ruff --output-format-github .
continue-on-error: true
- name: Test with unittest
run: |
python -m unittest discover tests
Thankfully, my project has no dependencies so I don't have to make pip install anything other than Ruff to lint my code, which you can see above. I only make my program run the testers with two versions of Python, 3.11 and 3.12. I chose these versions in particular because there is a library my program uses called tomllib. Tomllib is built into Python 3.11 and above, which means that my program does not support 3.10 and below. So I've only made it test with the two most recent versions of Python. I also wanted to attempt running my program on different OSs, like Ubuntu and MacOS, but I believe way those two OSs handle file paths differently from Windows. So when I was trying to handle file paths, it was expecting it in the Windows way and not the Linux way. So for now, it looks like my program does not work with Linux and MacOS. That concludes what I did for my workflow, next I'll talk about writing a test for a peer's program.
Writing a Test for a Peer's Program
I made a contribution to my peer's program called Waypoint. I made a contribution to their testers. The way they had it setup was different from mine. I had my program store all the testers in a tests folder for organizational reasons. I also split up the testers for each file, for example my testers for my helpers.py would have its own tester file. While my peer combined all their testers into one file. However, we both used unittest so I could just look at their code and jump right into creating a unittest. Thanks to my prior knowledge of making unittests for my program, this was simple. I created a tester to test the output of the function that handles Markdown conversion. I tested it, then committed and then made a PR. The tester worked with the CI my peer made and so they merged it. This leads me to my final thoughts about CI.
What do I think of CI?
I think that CI is a pretty handy tool for development, and I found the setup process to be really simple (for Python at least). I liked how I can use it to test my PRs on GitHub to make sure that the code I'm contributing works issue free. I also think that if I were to make another project, I would use CI in it. So, I'm definitely looking forward to how I can use it more in my programs, and what I can take advantage of to help me.
That's all for now. As always thank you for reading, and I'll catch you all in the next blog post.
Top comments (0)