USRSE / USRSE/usrse.github.io

Change linting workflow to only check modified files

Open
#1,601 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

discussion-needed
Dominant language
HTML
Stars
33
Forks
104
Avg merge
12h 3m
Merged PRs (30d)
10

Description

I forget if this has come up before, so I'm creating an issue here for discussion.

Would it make sense to change the linting workflow to only run urlcheck on the files that were modified as part of a PR?

The motivation here is: we have a large and growing list of links to check in the content of our site. The urlcheck job already takes a long time to run. Checking every single link on the site for trivial changes seems... excessive. It also causes confusion for PR submitters when something they didn't touch fails the workflow, i.e., "hey, do I need to fix that expired job link to get my new event announcement merged???"

One upshot of the current method is that it provides a somewhat routine check for all the links and provides quick feedback to an attentive person. If we were to change the scope of the linting workflow, we should probably add a new cron-triggered workflow to urlcheck all the links on a periodic basis, maybe weekly or monthly, but then some group of people would need to be alert for failures.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by locating the existing linting workflow and its urlcheck job. Determine how modified PR files are selected and define a scheduled full-site check; done means PR checks avoid unrelated links while periodic checking still covers all links.

Written by the indexing model from the issue text.

Assessment

Tech stack
github-actions
Domain
ci-cd
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.