Алексей

Да, можно настроить триггер запуска задачи при изменении определенного файла или каталога:
https://docs.gitlab.com/ee/ci/yaml/#ruleschanges

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile
      when: manual
      allow_failure: true

docker build alternative:
  variables:
    DOCKERFILES_DIR: 'path/to/dockerfiles'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - $DOCKERFILES_DIR/**/*

Если такой вариант не устраивает и надо выполнить какой-то скрипт и по его результатам запускать задачи, то у гитлаба есть API и через него можно запустить любую задачу: https://docs.gitlab.com/ee/ci/triggers/#trigger-a-...

Можно логи положить в артефакты, а потом их проверить на следующем шаге пайплайна и отправить нужное уведомление.

Отладьте скрипт в файле и вызывайте файл, лежащий в репо.

script:
    - powershell -File блаблаl\блабла.ps1

Либо в стандартном формате построчно:

script:
  - powershell -Command "блабла"  
  - powershell -Command "блабла2"

Ну ямл - это не повершелл, поэтому он не будет работать с его синтаксисом. Там нужно обозначить что ваша строчка это скрипт, по типу:

script:
    - echo "Build docker-image with sources"

Только без эхо само-собой, да и то я не знаком сильно с ямл, но судя по примерам в сети он может только cmd, а повершелл это прям другое, так что лучше запихнуть эту строку в файлик .ps1 и в шаблоне просто указать запуск этого файла в оболочке повершела.
Но это мои догадки.

К сожалению нет, но есть несколько способов, которые могут помочь вам ускорить или облегчить просмотр истории файла в git extensions. Они включают в себя:

1) Установить опцию --max-count для git log, чтобы ограничить количество показываемых коммитов. Например, git log --max-count=10 "src/filename" покажет только последние 10 коммитов, в которых был изменен файл. Это может сократить время ожидания и нагрузку на процессор.
2) Установить опцию --no-pager для git log, чтобы отключить использование программы less для показа вывода. Например, git log --no-pager "src/filename" покажет историю файла без задержки и возможности прокрутки. Это может быть полезно, если вы хотите просто посмотреть последние изменения файла.
3) Использовать фильтр по дате для git log, чтобы показать только коммиты, сделанные в определенный период времени. Например,

git log --since="2020-01-01" --until="2020-12-31" "src/filename"

покажет только коммиты, сделанные в 2020 году. Это может быть полезно, если вы знаете примерное время, когда файл был изменен.

если после номера задачи идет и перевод строки, то это уже не нахождение в строке.
от начала до не-цыфра простой регуляркой.
Если все цифры начинаются с номера, то можно так

sed -r 's/#.{0.1}\d*/replacement/g' file

В svn было довольно удобно ориентироваться на последовательные номера редакций.

В git точно так же можно ориентироваться на вывод git describe, в котором присутствует ближайшая метка (или выбранная метка, если делать git describe --match 'mask'), количество коммитов после этой метки и хеш последнего коммита. Например, в одном и том же дереве linux я вижу:

$ git describe
xtensa-6.8-rc2-esp32-spi-8-gb25ff15921c2
$ git describe --match 'v*'
v6.8-rc2-52-gb25ff15921c2
$ git describe --match 'v?.?'
v6.7-13495-gb25ff15921c2

голова отстоит на 8 коммитов от последней метки xtensa-6.8-rc2-esp32-spi, или на 52 коммита от последней официальной метки v6.8-rc2 или на 13495 коммитов от последнего релиза v6.7.

https://docs.gitlab.com/ee/ci/jobs/job_control.htm...

Но это но это будет нормально работать только для merge request.

Наверное проще всего положить код в разные репозитории и в каждом описать свой пайплайн

Попробуй на клиенте установить параметр SQLNET.OUTBOUND_CONNECT_TIMEOUT