Gitlab plugin uses the first commit to check if "[ci-skip]" is present,

https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L32-L35

It causes some CIs being skipped for no reason.

Impact: when rebasing feature branches, CI is skipped for no reason, causing developers to struggle (they have absolutely no clue why CI has "broken")

Current workaround is git commit --amend && git push -f

Consider the following:
1) feature_foo is branched from master and pushed to gitlab -> CI is triggered as expected
2) [ci-skip] commit is added to master -> CI is skipped
3) git checkout feature_foo && git rebase master && git push -> CI is skipped since push event for branch feature_foo includes all the commits, including [ci-skip] commit that was present in master branch before rebase.

I think only the latest commit should be used to tell if [ci-skip] is present or not.
Does it make sense?

A similar issue is around retrievePushedBy (the first commit is likely to be the least relevant one):
https://github.com/jenkinsci/gitlab-plugin/blob/c27af273327e1660d619a27045f0dd301af68067/src/main/java/com/dabsquared/gitlabjenkins/trigger/handler/push/PushHookTriggerHandlerImpl.java#L89

Just in case:
Jenkins 2.6
Gitlab plugin 1.2.3
Git plugin 2.4.4
Java 1.8u92
Gitlab 8.7.5