EmachinesDIMA

В официальных образах nginx достаточно создавать их в /etc/nginx/templates/ с суффиксом .template.
Файл с переменными на замену монтируется как /etc/nginx/templates/config.conf.template
Шелл скрипт, дёргаемый энтрипоинтом, копирует с подменой и получается /etc/nginx/conf.d/config.conf

Предположение 1:
> Uploading artifacts... found 1 matching files and directories

Он нашел одно совпадение. Быть может это именно каталог ${CI_PROJECT_DIR}/tmp/var/www/app, в котором не обнаружил файл artifact-$CI_JOB_NAME-$CI_COMMIT_REF_NAME. Для решения попробовать указать вместо вашего варианта, так. Не понятно как и какой файл создается в этом каталоге, вы этого не показывает, вероятно он просто не подходит под шаблон.

artifacts:
    when: always
    paths:
      - "${CI_PROJECT_DIR}/tmp/var/www/app/*" # именно в кавычках

Предположение 2:
Раннер запускается от своего пользователя, а файл создается от пользователя, под которым запускается процесс в контейнере, как правило, это рут, поэтому имеет смысл попробовать перед docker-compose дать 777 права на этот каталог:

script:
    - chmod 777 ${CI_PROJECT_DIR}/tmp/var/www/app

Предположение 3:
Маловероятно, вы же проверили, но на всякий случай проверьте еще раз, смущает частое упоминание /var/www/app в разных вариациях и не уверен, что это один и тот же каталог для хоста и контейнера. Например, ${CI_PROJECT_DIR}/tmp/var/www/app каталог для раннера это не одно и тоже, что и для контейнера.

И последнее:
Вы монтируете каталог /var/www/app, а создаете ${CI_PROJECT_DIR}/tmp/var/www/app

Фикстуры - это по сути тестовые данные. Они нужны для unit-тестирования. Это могут быть как данные в базе, так и обычные файлы (обычно 2 варианта, до и после обработки так скажем). Каждый раз когда запускаются тесты, эти данные используются для установления начального состояния системы, что бы тесты всегда выполнялись предсказуемо.

Для функционального тестирования (тестрирование контроллеров, интаграционных тестов) фикстуры не применяются, хотя суть там так же сходна. Если честно, то тут мнение расходится. Одни говорят что при функциональных тестах нельзя использовать даже моки, то есть система в процессе выполнения тестов полностью создает то состояние которое необходимо для других тестов. Например последовательное выполнение тестов на добавление статьи и ее просмотр. Другие же предпочитают для каждого тесткейса выставлять состояние с нуля. По сути это схоже с использованием фикстур, но реализация различается. У вас есть некое api для заполнения данными (скажем метод добавляющий пользователя), и перед выполнением тест-кейса происходит ресет данных и заполнение их новыми. Плюсы так же есть - можно распаралелить выполнение тестов. (но не верьте мне на слово)

Миграции - механизм организации версионности структуры проекта. Вы можете написать миграцию для изменения местоположения статики (картинки, поменять ссылки в базе и т.д.), или же у вас добавляется новая таблица/поле. Обычно дополняется обратной миграцией, которая восстанавливает исходную структуру. Обязательно для работы в команде или при частом изменении организации данных в проекте, вообще я бы посоветовал использовать их всегда.

Сосед попросил вас позвонить в газовую службу. Вы - прокси для соседа.
Несколько соседей попросили позвонить вас в газовую службу. Вы позвонили по первой просьбе, а на другие ответили, что уже звонили. Вы - кеширующая прокси для соседей.
Сосед взял ваш телефон и позвонил в газовую службу с вашего номера. Вы - NAT для соседа.

from ldap3 import Server, Connection, SUBTREE

s = Server(ad_domain, use_ssl=True, port=636)  # Адрес домена, шифрование, порт
c = Connection(s, ad_admin, ad_password)

# Поиск учётной записи в домене (Active Directory) по фамилии или логину
def search_ad(last='*', login='*'):
    c.bind()
    c.search('ou=Офис, dc=domain, dc=local',
             '(&(objectCategory=Person)(sn={})(sAMAccountName={}))'.format(last, login), SUBTREE,
             attributes=['sAMAccountName', 'givenName', 'sn', 'cn', 'whenCreated', 'lastLogon', 'pwdLastSet',
                         'msDS-UserPasswordExpiryTimeComputed', 'memberOf', 'ipPhone', 'lockoutTime',
                         'distinguishedName'])
    a = c.entries
    c.unbind()
    return a

# Вывод информации учётной записи в домене (Active Directory)
def change_ad(cn):
    c.bind()
    c.search('ou=Офис, dc=domain, dc=local', '(&(objectCategory=Person)(cn={}))'.format(cn), SUBTREE,
             attributes=['sAMAccountName', 'givenName', 'sn', 'cn', 'whenCreated', 'lastLogon', 'pwdLastSet',
                         'msDS-UserPasswordExpiryTimeComputed', 'memberOf', 'ipPhone', 'lockoutTime'])
    a = c.entries
    for ad_user in c.entries:
        name = ad_user['givenName']
        last = ad_user['sn']
        login = ad_user['sAMAccountName']

# Отправка электронного письма
def send_email(message):
    msg_email = MIMEMultipart()

    msg_email['From'] = email_from
    msg_email['To'] = email_to
    msg_email['Subject'] = 'Тема'

    body = 'Текст сообщения'

    msg_email.attach(MIMEText(body, 'plain'))

    server = smtplib.SMTP_SSL('smtp.yandex.ru:465')
    server.login(email_from, email_password)
    text = msg_email.as_string()
    server.sendmail(email_from, email_to, text)
    server.quit()

Накидал скрипт, думаю то, что вам нужно.

$users = Import-Csv -Path "C:\test\test.csv" -Encoding Default -Delimiter ","
$AD = Get-ADUser -filter *

#Указание параметров почтового сервера
$EmailFrom = "email@address.ru" #необходимо указать адрес от имени которого будут отправляться письма
$Subject = "Тема письма" #необходимо указать тему письма
$smtpServer = "smtp.mail.ru" #необходимо указать адрес почтового сервера
$smtp = New-Object net.mail.smtpclient($smtpServer)
####################################

foreach ($user in $users)
{
$username = $user.name
$EmailTo = $ad | where-object {$_.name -like "*$username*"} | Select-Object UserPrincipalName
$EmailTo = $EmailTo.UserPrincipalName
$Monitor = $user.Monitor
$Mouse = $user.Mouse
$Body = "Monitor - $Monitor Mouse -$Mouse"
$smtp.Send($EmailFrom, $EmailTo, $Subject, $Body)
$EmailTo = $Null
}

Кат - это специальный тег, который разделяет пост на 2 части: "до ката" (вступление) и "после ката" (продолжение статьи). До ката должна находиться информация, максимально завлекающая под кат. Поэтому может находиться где угодно - после первого предложения, после первого абзаца, после картинки до ката (КДПВ - Картинка Для Привлечения Внимания).

Выполните деплоймент вручную, используя только консольные команды.

Запомните все, что вы сделали, напишите из этого скрипт, создайте в тимсити джобу с этим скриптом и запускайте.

В случае необходимости, установите необходимый софт на тестовый стенд (git/bash/etc). Возможно вам понадобится еще один тимсити агент, установленный прямо на тестовую виндовую машину.

Старый надежный robocopy с ключами "/mir /sec /secfix"

Если вы хотите обновить у себя
git pull
Если вы хотите залить изменения на удаленный git-репозиторий
git push

Надо папку с вложенным .git прописать в файл .gitignore в корневой папке верхнего репозитория : folder/
Тогда git не будет отслеживать изменения в ней.
Всё, можно пользоваться раздельно.

virtualenv никак не связан с твоим проектом. Это python, который отделён от других в системе. Проект может лежать где угодно. Несколько проектов могут использовать один virtualenv. Если тебе нужны другие python пакеты для другого проекта и ты хочешь их отделить надо создать ещё один virtualenv.

Делаем корневую папку, проект, в ней 2 , одна с окружением, вторая с гитом.
Все ...
Виртуальное окружение ни кто в гит не пихает ...