radio-t-site
radio-t-site copied to clipboard
radio-t
Add to youtube
Сделал из папки /publisher docker-контейнер. Можно запускать скрипты так:
docker-compose run --rm publisher {scriptName} [args…]
Также в контейнер при сборке добавляются скрипт на go для загрузки в YouTube — add-to-youtube. Написал его на Go, т.к. это проще, чем скрипт на shell. 🙄
Также добавил README к паблишеру. Для работы скрипта в папке /publisher/secrets должен лежать файл client_secret.json.
В данный момент add-to-youtube делает видео из статичной картинки publisher/assets/cover.webp. Это самый не затратный способ по объёму, что я смог сделать. Может, если найдётся гуру ffmpeg, он сделает лучше.
#37
мне не совсем понятно почему все это дело в 3х каталогах под publisher. хорошо бы все консолидировать в одном "youtube" и в нем уже внутри все, что тебе надо
мне не совсем понятно почему все это дело в 3-х каталогах под publisher. хорошо бы все консолидировать в одном "youtube" и в нем уже внутри все, что тебе надо
Да, так и сделаю.
по моему, у тебя потерялся
go.sum
Вроде есть — https://github.com/arthurgubaidullin/radio-t-site/blob/add-to-youtube/publisher/add-to-youtube/go.sum
хорошо бы ему свой README со всем тем, что ты вписал в общий. А в общем на него сослаться
хорошо бы ему свой README со всем тем, что ты вписал в общий. А в общем на него сослаться
В папку add-to-youtube свой README? Ok.
и еще - было бы неплохо заиметь .travis.yml Я не уверен, как травису велеть строить из внутреннего каталога, но подозреваю что делается
В папку
add-to-youtubeсвой README?
ну да. Сейчас там вообще непонятно что это все относится к youtube
ну да. Сейчас там вообще непонятно что это все относится к youtube
Да, надо действительно как-то отделить.
и еще - было бы неплохо заиметь .travis.yml Я не уверен, как травису велеть строить из внутреннего каталога, но подозреваю что делается
Я с трэвисом не работал. А что он должен строить, go build?
он может запустить все твои тесты на каждый комит, плюс линтеры, типа как тут https://github.com/go-pkgz/rest/blob/master/.travis.yml
Но не заморачивайся с этим, я потом добавлю
Сделал из папки
/publisherdocker-контейнер. Можно запускать скрипты так:docker-compose run --rm publisher {scriptName} [args…]
Я сильно сомневаюсь, что это будет работать в общем случае. Т.е. для чего-то, что не youtube publisher. Там много чего не будет хватать для прочих действий. Просто прокинуть туда все в виде - ./:/publisher недостаточно. Насколько я понимаю, ты это делаешь именно для других частей, т.к. твой контейнер все это строит и не нуждается в примаунтенном /publisher. Я даже не очень понимаю, как оно вообще может работать - в Dockerfile ты все строишь в /publisher/ а потом переопределяешь это в композе. Что то тут не так
Я сильно сомневаюсь, что это будет работать в общем случае. Т.е. для чего-то, что не youtube publisher. Там много чего не будет хватать для прочих действий. Просто прокинуть туда все в виде
- ./:/publisherнедостаточно. Насколько я понимаю, ты это делаешь именно для других частей, т.к. твой контейнер все это строит и не нуждается в примаунтенном /publisher. Я даже не очень понимаю, как оно вообще может работать - в Dockerfile ты все строишь в /publisher/ а потом переопределщешь это в композе. Что то тут не так
Для бинарника add-to-youtube нужна только папка assets с обложкой. Я же бинарник кладу в /usr/local/bin/. 😄
Вообще, я не знаю как другие скрипты запускаются, поэтому оставил возможность запуска их в контейнере.
идея мониторвать внутрь контейнера все и брать что-то из конкретных папок мне сильно не нравится. Конечно, если тебе надо монтировать что-то динамическое (типа hugo/posts или папку картиног) то в таком конкретном маунте есть смысл. Но это стоит делать прямо и, по виозможности, :ro.
идея мониторвать внутрь контейнера все и брать что-то из конкретных папок мне сильно не нравится. Конечно, если тебе надо монтировать что-то динамическое (типа hugo/posts или папку картиног) то в таком конкретном маунте есть смысл. Но это стоит делать прямо и, по виозможности,
:ro.
Сделал :ro.
Кажется, я нашел способ существенно ускорить создание видео и youtube не воротит нос от этого файла. При этом Youtube будет делать долго свою пост обработку.
Мне кажется этот вариант лучше. Или оставить долгую обработку у нас?
У нас "до" — больше чем длиться подкаст, "после" — меньше минуты. У YouTube "до" — пост обработка вроде короткая, а "после" — дольше.
ну тут и вопросов нет. Такая долгая обработка на нашей стороне нам просто не подходит. То, что оно на YouTube будет делаться долго, это гораздо предпочтительней чем у нас