Список будет пополнятся :)

Dockerfile:

• Минимальная версия докера Docker version 19.03.13, build 4484c46d9d
• Базовый образ ubuntu:22.04
• Не использовать Expose
• При установке любых пакетов и программ (в том числе в requirements) ВСЕГДА указывать версии
• Ограничить установку зависимостей apt одной строкой (один RUN)
• Если настройка одной части приложения состоит из нескольких команд → необходимо разместить их в одном слое (в одном RUN)

Docker-compose:

• Минимальная версия docker compose version 1.27.4, build 40524192
• Все должно собиратся по команде docker-compose build без sudo
• Не использовать тип сети HOST
• Не отрывать лишних (непредусмотренных заданием) портов
• Не использовать порты хост-машины ⇐1024
• Не открывайте лишний раз порты всему миру (`5000:5000`). Тут, на самом деле, вообще не вижу необходимости их открывать, но если надо, можно открыть на localhost (`«127.0.0.1:5000:5000»`)
• Не используйте автоматически сгенерированные имена контейнеров (вроде `docker exec 9310_molodtsev_da-test-1…`), они могут изменится. Если вы не указываете `container_name` (не надо), можно писать `docker compose exec test …`
• Не используйте `container_name` в `docker-compose.yml` без необходимости. Это только создаст проблемы, если вы где-то попробуете поднять такой же docker-compose с таким же названием. Вместо `docker exec <container-name>` можно использовать `docker compose exec <service-name>`, где `<service-name>` - ключ в yaml-файле.

https://docs.google.com/spreadsheets/d/1Tk7py40c2guXg82FIlYvp5BF9DYnMFcatnOCnKyLXH4/edit#gid=0

Подсказки по условиям вашего задания - ниже.

• Построение тестов
  • Проверка на соответствие стилю кодирования / бьютификакция - подключаем проверку стиля кодирования (технологии ниже) и встраиваем ее в цепочку запуска
    • Проверка на pep8 - используем https://pypi.org/project/pep8/
    • Форматирование Python (yapf) - https://github.com/google/yapf
    • Форматирование Python (black) - https://github.com/psf/black
    • Форматирование Python (flake8) - https://github.com/PyCQA/flake8
    • Форматирование HTML, JS (prettier) - https://prettier.io
    • Форматирование Python (pindent) - http://svn.python.org/projects/python/trunk/Tools/scripts/pindent.py
    • Форматирование Python (pybetter) - https://github.com/lensvol/pybetter
    • Форматирование Python (ssort) - https://github.com/bwhmather/ssort
    • Форматинование Pyhton (usort) - https://github.com/facebook/usort
    • Проверка бьютификатором для HTML - https://pypi.org/project/html-linter/
    • Причесывание бьютификатором HTML - https://pypi.org/project/css-html-prettify/
    • Проверка бьютификатором для JS - https://pypi.org/project/pyjslint/
  • Статический анализ - подключаем статическую проверку (через pylint) и встраиваем ее в цепочку запуска
    • Анализ по 10 существующим критериям - выберите по 10 уникальных критериев проверки, настройте запуск на них и допустите все десять ошибок в коде проекта:)
    • Создание своего критерия и проверка только по нему - проверяем на наличие переменных, название которых совпадает с вашим именем
  • Интеграционные тесты - пишем интеграционные тесты (через requests) и встраиваем их в цепочку запуска
    • Проверка на коды возврата
    • Проверка на заголовки
    • Проверка на загрузку файла
  • Selenium - пишем selenium тесты и встраиваем их в цепочку запуска (нельзя использовать для selenium отдельный контейнер, реализуйте тесты в рамах контейнера tester). См. описание ниже.
• Docker
  • Внешний SSH доступ в контейнеры - организуем доступ через протокол SSH контейнер одним из следующих способов: или по ключу в каталоге с проектом, или генерируем пароль для доступа и сообщаем его при сборке / запуске, или генерируем новую пару ключе и выводим их в файлы. Порт для SSH должен быть доступен снаружи docker-compose конфигурации.
    • В app - по публичному ключу (существующему)
    • В tester - по публичному ключу (существующему)
    • В app и tester - по публичному ключу (существующему)
    • В app - по паролю
    • В tester - по паролю
    • В app и tester - по паролю
    • В app - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
    • В tester - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
    • В app и tester - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
  • Вывод логов работы tester - задание о том, куда и как выводить логи тестирования в контейнере tester
    • Каждый этап тестирования - в docker log (stdout + stderr) и в отдельный файл оба потока по каждому виду тестирования Совместно выводим логи тестирования (stdout + stderr) так, чтобы их видел и docker logs, и они собирались в файле.
    • Каждый этап тестирования - в docker log ( stdout + stderr) и в общие файлы (отдельно - для stdout, отдельно - для stderr) - Совместно выводим логи тестирования (stdout + stderr) так, чтобы их видел docker logs, но при этом в один файл сохраняем stdout логов, в другой - stderr.
    • Каждый этап тестирования - в docker log (stdout + stderr) + добавить к записям лога timestamp - помимо вывода в docker log нужно также сделать, чтобы перед каждой записью в логе стоял timestamp (или текущее дата и время)
• Docker-compose
  • Передача параметров в конфигурацию через .env, какие параметры передаем - нужно сделать как пример env файла, так и смаппить (А кое где и написать скрипты настройки) параметры на нужное поведение
    • Порт для веб-сервера - публичный порт, на котором слушает веб-сервер
    • Список этапов тестирования для запуска - список шагов из пункта «Построение тестов», которые будут запущены. Если не задано, запускаем все этапы. Если задано - то только указанные.
    • Публичный SSHключ для доступа в контейнер(ы) - это отдельный ключ, не связанный с заданием «Внешний SSH доступ в контейнеры» из предыдущего раздела.
    • Ключ отладки для Flask - флаг отладочной работы (debug) для Flask приложения
  • Органичения ресурсов - ограничения ресурсов для контейнеров в docker-compose.yml
    • ОЗУ - ограничьте доступную каждому из контейнеров ОЗУ до объема 100 + НОМЕР_ВАРИАНТА * 10 МБ
    • Ядра процессора - ограничьте доступные в каждом контейнере количество ядер ЦПУ до (1 + НОМЕР_ВАРИАНТА % 2) (остаток от деления номера вашего варианта на два)
    • Максимальное Количество процессов - ограничьте до количества НОМЕР_ВАРИАНТА

Задача в написании Selenium-тестов - написать автотесты для нескольких форм ИС ИОТ. Тестовый инстанс находится по адресу https://test.digital.etu.ru/trajectories/.

Тест должен включать в себя следующие шаги:

1. Авторизация через ETU ID.
   • Используйте ваш логин/пароль из ЛК ЛЭТИ. Укажите их в .env-файле, коммитить в репозиторий не нужно
   • Вы должны получить в системе права администратора. Если не получите - пингуйте нас в Discord.
   • В системе все персональные данные заменены на сгенерированные.
2. Если ваш вариант включает в себя работу с ОПОП, РП или формой «Распределение документов», авторизуйтесь за пользователя id=1305 (Schimmel Вадим August) на форме «Авторизация за другого пользователя». У этого пользователя есть все права на все документы.
3. Проверьте функционирование формы, указанной в задании:
   • Инструкции по формам есть по ссылке: https://digital.etu.ru/doku.php?id=navigation:iot
   • Большинство форм включают в себя сохранение какого-то состояния (вкладки документа, выдача прав и т.п.). В таком случае задача - ввести в форму какие-то значения (не обязательно осмысленные), сохранить, обновить страницу и проверить, что внесенные данные сохранены.
   • В работе с документами - можете создать новый документ или взять существующий в статусе «черновик». Если создаете новый, не забудьте удалить.
   • В работе с документами - берите документы с кафедрой, соотвествующей вашему положению в таблице «Варианты заданий» (см. ниже). Так мы избежим конфликтов из-за одновременного выполнения тестов.
   • В работе с пользователями - берите пользователей, у которых фамилия соответствует вашей сгенерированной (можно посмотреть сверху в сайдбаре).

Кафедра, в которой вы работаете = (ваш номер в «Варианты заданий») % 40 + 1.

Кафедры:

1. каф.АМ
2. каф.ЛИНС
3. каф.ЭПУ
4. каф.ИИСТ
5. каф.ВМ
6. каф.МНЭ
7. каф.РАПС
8. каф.ЭП
9. каф.ЭУТ
10. каф.ФЛ
11. каф.ИМ
12. каф.ТВ
13. каф.МОЭВМ
14. каф.МСК
15. каф.БЖД
16. каф.СО
17. каф.ВТ
18. каф.САПР
19. каф.ФЭТ
20. каф.Фот
21. каф.МВЭ
22. каф.ПМИГ
23. каф.ИНЯЗ
24. каф.ТОЭ
25. каф.СП
26. каф.ПЭ
27. каф.ТОР
28. каф.БТС
29. каф.РС
30. каф.САУ
31. каф.ИКГП
32. каф.ЭТПТ
33. каф.РЯ
34. каф.МИТ
35. каф.ФХ
36. каф.РЭС
37. каф.ИЗОС
38. каф.АПУ
39. каф.ИС
40. каф.ФВиС

Это не все кафедры ЛЭТИ, только те, по которым есть более 100 РП.

Вам необходимо реализовать docker-compose конфигурацию из двух узлов (не больше и не меньше):

• app - контейнер с существующим демонстрационным веб-приложением (https://github.com/moevm/devops-examples/tree/main/EXAMPLE_APP).
  • Устанавливать приложение необходимо скачивая репозиторий https://github.com/moevm/devops-examples и копируя файлы из него при сборке вашего контейнера:)
  • Чтобы все заработало, вам придется потратить время и поразбираться - из коробки может не работать.
  • Возможно, вам для выполнения заданий потребуются фиксы в исходник - делайте для них патчи ( https://man7.org/linux/man-pages/man1/patch.1.html)
  • Корнем дерева процессов выступает запущенное веб-приложение
• tester - контейнер для запуска всех тестов (состав и особенности тестов задаются в таблице вариантов)
  • Корнем дерева процессов выступает стандартный python http сервер (python -m http.server 3000)
  • Этот сервер должен быть запущен в каталоге контейнера, где будет происходить работа тестовых скриптов
  • Тестовые скрипты запускаются через docker exec

Оба контейнера должны использовать написанные вами образы, собираемые из локальных Dockerfile. Шаблоны для имен Dockerfile:

• Dockerfile_app
• Dockerfile_tester

Помимо Dockerfile, вам также необходимо сделать файл README.md, содержащий примеры команд для запуска тестов и проверки всей конфигурации. Это сильно ускорит проверку:)

Параметры конфигурации задаются в таблице вариантов + общие требования (http://se.moevm.info/doku.php/courses:devops:project#общие_требования).

1. Автоматизация тестирования курсовых по Android

Идея - разработать набор github actions, которые будут по состоянию репозитория проверять (базово) соответствие этапам выполнения работы и генерировать / отображать статус в readme.

Подробности об этапах:

https://se.moevm.info/doku.php/staff:courses:application_development_for_mobile_platforms:course_work:topics

Проверяем:

1. Макет и UC (есть вики страница, файл макета загружен в репо)
2. UI на заглушках (если задан нужный тег- проверяем наличие исходников андроид проекта, его собираемость через github actions, .gitignore , название пакета )
3. Юнит-тесты ( тег, сборка и запуск)
4. App is ready (тег, требования, запуск, запуск стресстестов)
5. Оценка сложности UI вашего приложения (вики станица и ее содержимое)
6. Пояснительная записка (наличие файлов )
7. Интеграционные тесты ( тег, сборка и запуск)

Используем в качестве технологий github actions. Сдаем отдельным репо.

2. Проверка корректности учебных работ на языке Python (командная строка)

Идея - автоматизировать процесс проверки лабораторных и курсовых работ.

Для проверки кода - pylint, для тестирования работы в командной строке https://github.com/cucumber/aruba, для профилирования работы - valgrind.

Формат выполнения github actions. Сдаем отдельным репо.

Этапы проверки

• Успешная проверка на явные синтаксические проблемы через линтер(не запустится, нет комментов, невменяемые имена переменных….)
• Успешное тестирование работы на заранее известных примерах аргументов командной строки (== приложение не падает с заранее известными аргументами )
• Стресс-тестирование аргументов командной строки (проверка, что если подавать почти рандомные аргументы, приложение не сломается. Аргументы необходимо генерировать рандомно, но в соответствии с описанием ожидаемой структуры )
• Стресс-тестирование stdin
• Профилирование работы по памяти и времени ( valgrind + time)

3. Проверка корректности учебных работ на языке С (командная строка)

Аналогично теме 2, но компилируем в gcc (и проверяем что все ок с компиляцией) + другие линтеры.

Оценка за проект складывается из следующих критериев (пропорционально степени выполнения вашего варианта задания):

• (0-10 баллов) Требования к организации тестов из вашего варианта
• (0-10 баллов) Требования к работе в Docker
• (0-10 баллов) Требования к работе в составе Docker-Compose

Подробно о процедуре проверки https://docs.google.com/document/d/1iqn_jtQ7yP_jgMv1a-jw3qriWTVHDyAeEPAnQT51tl8/edit

Все работы сдаются только и исключительно в виде PR в репозиторий курса. Подробно:

https://github.com/moevm/devops-1h2024/blob/main/README.md

Если у вас сложности:

• Примеры скриптов и тестов https://github.com/moevm/devops-examples/tree/main/selenium_tests
• Курс https://stepik.org/course/575
• Старая, но актуальная лекция про Selenium https://www.youtube.com/watch?v=gLj6BMmI69I