I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
By looking at the commits since the last build and stubbing out the stages/jobs for things that didn't change.
Most CI systems either already give you a list of what commits the build is for, or they provide some easy way to find out, and even if they don't, you can save the state of the previous build somewhere to compare against.
Once you have that list of commits, you can easily get a file list (for example: git diff --name-only ${COMMIT1}..${COMMIT2} from the root of the repo) and match on that file list to decide whether to actually run a stage/job or not.
See this script for an example of doing this on Travis, with appropriate special handling for PR's. I've been working on a post about this actually, but just haven't finished it yet.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
By looking at the commits since the last build and stubbing out the stages/jobs for things that didn't change.
Most CI systems either already give you a list of what commits the build is for, or they provide some easy way to find out, and even if they don't, you can save the state of the previous build somewhere to compare against.
Once you have that list of commits, you can easily get a file list (for example:
git diff --name-only ${COMMIT1}..${COMMIT2}from the root of the repo) and match on that file list to decide whether to actually run a stage/job or not.See this script for an example of doing this on Travis, with appropriate special handling for PR's. I've been working on a post about this actually, but just haven't finished it yet.