Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Get CI running again #1035

Merged
merged 6 commits into from
Feb 3, 2023
Merged

fix: Get CI running again #1035

merged 6 commits into from
Feb 3, 2023

Conversation

matthewfeickert
Copy link
Contributor

I saw that jupytext's CI was broken so thought I'd try to help fix it. There's lots of cleaning that could be done on the CI, but this just gets it running again.

This updates all the GitHub Actions to their latest releases and updates and applies the pre-commit hooks so those pass as well. It additionally fixes the dependency conflicts happening by trying to install the linting dependencies for older Pythons by just having the lint job be separate as it only needs to run once, not for every Python being tested.

I also threw in the use of python -m pip pattern over just pip even though it isn't needed to try to spread this best practice to others who might be looking at jupytext's CI. Feel free to ask for that to be removed if you aren't a fan.

* Update actions/checkout to v3
* Update actions/setup-python to v4
* Update actions/cache to v3
* Run 'pre-commit autoupdate'
* Add a lint job that is seperate from the testing as this is
  independent of the rest of the tests and only needs to be run once
  rather than multiple times.
* Remove the linting with flake8 from the test jobs and make them
  require the 'lint' job to have passed to run. This has the same
  effect but avoids the possibility of dependency conflicts.
@matthewfeickert
Copy link
Contributor Author

@mwouts this is ready for review.

@mwouts
Copy link
Owner

mwouts commented Feb 3, 2023

Wow thank you so much @matthewfeickert , this is very helpful! I will have a look at this asap.

@mwouts mwouts merged commit e097422 into mwouts:main Feb 3, 2023
@mwouts
Copy link
Owner

mwouts commented Feb 3, 2023

This looks really great! Thanks again.

I see in your comment above that more cleaning could be done, that could be a great idea, feel free to tell us more about that!

@matthewfeickert matthewfeickert deleted the fix/fix-ci branch February 3, 2023 17:13
@matthewfeickert
Copy link
Contributor Author

I see in your comment above that more cleaning could be done, that could be a great idea, feel free to tell us more about that!

Sure. Some of this is just matters of preference, and obviously whatever works best for you is what you should do, but I've found it easier to maintain GitHub Actions workflows by separating them out into multiple workflows rather than having them all exist in one, like you normally would do for Travis CI, GitLab pipelines, etc. So for example, the

analyse:
name: Analyse
needs: skip_duplicate
if: ${{ needs.skip_duplicate.outputs.should_skip == 'false' }}
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
with:
# We must fetch at least the immediate parents so that if this is
# a pull request then we can check out the head.
fetch-depth: 2
# If this run was triggered by a pull request event, then checkout
# the head of the pull request instead of the merge commit.
- run: git checkout HEAD^2
if: ${{ github.event_name == 'pull_request' }}
# Initializes the CodeQL tools for scanning.
- name: Initialize CodeQL
uses: github/codeql-action/init@v1
# Override language selection
with:
languages: python, javascript
- name: Perform CodeQL Analysis
uses: github/codeql-action/analyze@v1

job doesn't need to live in your CI workflow, but could exist as a separate codeql-analysis.yml workflow.

Also, unless I'm mistaken about its purpose, the

skip_duplicate:
runs-on: ubuntu-latest
outputs:
should_skip: ${{ steps.skip_check.outputs.should_skip }}
steps:
- id: skip_check
uses: fkirc/skip-duplicate-actions@master
with:
github_token: ${{ github.token }}

can be replaced with GitHub Actions concurrency control (c.f. https://docs.github.com/en/actions/using-jobs/using-concurrency). i.e. something like

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

These are just some thoughts, but more discussion would probably be better done in an Issue. I'll make one from this comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants