пайплайн запускается автоматически, если в проекте есть .gitlab-ci.yml, и запускает с теми изменениями, что есть
Пайплайн запускается с тем .giitlab-ci.yml, который лежит в ветке/теге для которого запускается пайплайн. Если запускаете пайплайн для ветки dev то и редактировать его нужно в ветке dev, а не master. Аналогично с тегами, пайплайн будет запускаться только с тем .gitlab-ci.yml который лежит в этом теге.
Но есть нюанс с merge request, там пайплайн запускатся для той ветки, в которую идёт merge. Т.е если вы делаете MR dev -> master - MR запустит пайплайн по .gitlabi-ci.yml ветки master, а не dev
Василий Банников, обычно так делали если нет достаточного места на плате, либо влом разводить землю и проще кинуть через корпус. ничего критичного в этом не вижу
Ziptar, с того что чтение и запись становятся медленнее. чтобы узнать какой уровень заряда необходимо подать на ячейку уровень заряда не меньше того что в ней находится, соответственно необходимо начинать с минимального значения и идти по нарастающей, в худшем случае выходит 2^4 попыток чтения на одну ячейку.
поизучайте доступные в интернете материалы по устройству SSD, глядишь вопросов меньше станет
aleks-th, QLC от SLC отличаются только зарядом в ячейке, в SLC всё просто: условно есть заряд - 1, нет заряда - 0, в QLC хранится 4 бита и соответственно 2^4 уровня заряда.
если заставить контроллер читать/писать только по одному уровню - получится SLC, что собственно и получилось у энтузиаста который провёл эту операцию с другим диском
Shurik, индикация выводится не по уровню сигнала, а по соотношению сигнал/шум. если в сигнале много мусорных данных вместо обмена с базой то и индикация будет ближе к нулю, иначе нет никакого смысла в такой индикации.
В вашем случае связь с базой хорошая, но сеть перегружена. В случае работы глушилки у вас сеть должна постоянно пропадать/появляться и соответственно отваливаться подключение