I have a scheduled GitLab CI job to check when the last commit was for a specific folder in a repository:
ERROR_THRESHOLD="2 weeks ago"
WARNING_THRESHOLD="1 week ago"
TWO_WEEKS_AGO=$(date -d "${ERROR_THRESHOLD}" +%s)
ONE_WEEK_AGO=$(date -d "${WARNING_THRESHOLD}" +%s)
LAST_COMMIT=$(git log -1 --format="%at" -- example_directory)
# IF ( NOT( LAST_COMMIT is more recent than TWO_WEEKS_AGO ) )
if ! (( $LAST_COMMIT > $TWO_WEEKS_AGO )); then echo "Last commit was more than two weeks ago" >&2 ; exit 20; fi
IF ( NOT( LAST_COMMIT is more recent than ONE_WEEK_AGO ) )
if ! (( $LAST_COMMIT > $ONE_WEEK_AGO )); then echo "Last commit was more than one week ago" >&2 ; exit 10; fi
(The CI is set to treat exit 10 as skippable.)
When I run this on most machines, it works as expected, but suddenly on some machines it is showing the wrong commit - it shows the last commit to the whole repository instead of the last commit on that directory.
When I run git show xxxx for the commit returned by git log, it doesn't show any changes to that folder.
How can I make sure to only get the commit that affects that directory?
GitLab limits the number of commits that the CI runner pulls from the server. Otherwise, it would take an inordinately long time to run jobs on older/larger repositories.
It could be that the files you are looking at just weren't modified in that number of commits.
The default number of commits is 20, but you can adjust it in multiple ways.
The simplest way is to set the GIT_DEPTH environment variable. The maximum is 1000, or you can set it to 0 to make the runner do a full fetch every time.
I haven't tested this myself, but you can probably also allow it to do the shallow commit and then do a git fetch --unshallow to get more commits. Depending on the size of the repository, this may be a bad idea.