Day 15: Failing CI to help fixing filesystem issues in a Python package

ci-2022-12 (27 Part Series)

1 The 2022 December CI Challenge
2 Day 2: Add GitHub Action CI to the Net-Async-Redis-XS Perl module
… 23 more parts…
3 Day 1: Test and CI for MoreBeautifulPython
4 Day 3: CI for farmworld, a Python package – a failed attempt
5 Day 3 v2: GitHub Action CI for wsblib Python
6 Day 4: GitHub Actions for Colombian Spanish.
7 Day 5: CI for Win32-Wlan Perl module
8 Day 6: GitHub Actions CI for the pcr_optimizer Python package
9 Day 7: Be pragmatic setting up CI for the RDF::KV
10 Day 8: Adding CI to Perl::Efl – sometimes you need to do some extra work
11 Day 9: CI for Mojo-UserAgent-Cached and Plack-Middleware-Greylist
12 Day 10: GitHub Actions CI for the rdf-kv Ruby Gem
13 Day 11: CI for wp2txt Ruby project
14 Day 12: CI for sdk-py Python packages
15 Day 13: CI for a Python project of the National Institute of Standards and Technology
16 Day 14: CI for the Log::Any Perl module
17 Day 15: Failing CI to help fixing filesystem issues in a Python package
18 Day 16: Moving from Travis-CI to GitHub Actions for Marpa::R2
19 Day 17: A JavaScript bug and GitHub Workflow CI for the four-pillars Ruby gem
20 Day 18: GitHub Workflow for ruby-request-builder – false security
21 Day 19: CI for Plack-Middleware-LogAny
22 Day 20: Skeletons are good, but can be misleading – CI for the draftjs_html Ruby Gem
23 Day 21: CI for multi_string_replace Ruby Gem
24 Day 22: Full gas in neutral – CI for prepper
25 Day 23: CI using timescaledb a PostgreSQL based time series database
26 Day 24: CI for perl5-MIME-Types
27 Day 25: CI for Data::Alias in Perl – including threaded perl

A few days ago, while I was looking for a Python package to set up with CI, I bumped into the vfxpaths. I tried to run the tests on my Ubuntu-based Docker container, but they failed due to some path-issues I reported.

Yesterday the author updated the issue saying that it has been fixed so today I tried it again.

It failed again, but this time on a test-file that was added a few hours ago. I updated the issue, but now that I see the author is actually interested fixing this issue, I though it might be more useful if I configured GitHub Action on the 3 platforms.

Once this pull-request is accepted on every push the tests will run on Linux, Windows, and macOS so the author will get almost immediate feedback if the path issue was solved and later if that or anything else breaks again it will be much faster to notice and therefor much easier to fix.

GitHub Actions

name: CI

on:
  push:
  pull_request:
  workflow_dispatch:
# schedule:
# - cron: '42 5 * * *'

jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        runner: [ubuntu-latest, macos-latest, windows-latest]
        python-version: ["3.11"]

    runs-on: ${{matrix.runner}}
    name: OS ${{matrix.runner}} Python ${{matrix.python-version}}

    steps:
    - name: Checkout
      uses: actions/checkout@v3

    - name: Set up Python ${{ matrix.python-version }}
      uses: actions/setup-python@v4
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install dependencies
      run: |
        # pip install -r requirements.txt
        pip install pytest

    - name: Check Python version
      run: python -V

    - name: Test with pytest
      run: pytest -vs

Enter fullscreen mode Exit fullscreen mode

Conclusion

Sometimes there is clear evidence that having a CI running on every push can shorten the feedback cycle and allow people who might have no direct access to all 3 operating system (which is about everyone) to see if their code works there and to experiment fixing issue on other platforms as well.

ci-2022-12 (27 Part Series)

原文链接：Day 15: Failing CI to help fixing filesystem issues in a Python package

文章版权声明 1、本网站名称：拾光赋
2、本站永久网址：https://www.blogs.ink
3、本网站的文章部分内容可能来源于网络，仅供大家学习与参考，如有侵权，请联系站长QQ：805375623进行删除处理。
4、本站一切资源不代表本站立场，并不代表本站赞同其观点和对其真实性负责。
5、本站一律禁止以任何方式发布或转载任何违法的相关信息，访客发现请向站长举报
6、本站资源大多存储在云盘，如发现链接失效，请联系我们我们会第一时间更新。

THE END