А вот за эту ссылку огромное спасибо! Жаль не понятно вернут ли эти деньги при выезде, как это делают в случае с отказом от PR. Если вернут так вообще прекрасно, т.к. это 100% прибыли на эту сумму будет в итоге.
Вы не поняли, идея (пока в виде предложения от депутата) оформить подписку собирать с работодателя дополнительную плату (1200 SGD) за иностранца в штате каждый месяц, чтобы мотивировать нанимать местных. Никакого возврата как в случае отказа с PR не будет.
PsyHaSTe подскажите, а у вас работает intelli sense в IDE/text editor с sqlx макросами (да и вообще с макросами)? Я пробовал пару раз sqlx (у самого IDEA c Rust плагином), но как только дописываю ключевое слово макроса на этом помощь IDE заканчивается.
а нельзя было остаться на основной работе… как-то выделить время по вечерам и выходным для своего pet-проекта
Нужно смотреть условия в контракте. Там вполне может быть что-то типа такого: все права на разработанное ПО в течение трудоустройства принадлежит работодателю.
По поводу самостоятельного развертывания, есть self-hosted runners.
Вставлю свои пять копеек, мы используем у себя частично (есть также jenkins, и совсем немного bibtucket pipelines).
Так вот, github actions все еще страдает мелочными проблемами, даже несмотря на версию v2.
Список досадных мелочей и проблем, с которыми я встретился:
конструкция if: always(), позволяет выполнить шаг даже если задача была отменена или завершилась с ошибкой. Вполне возможно, что я уже придираюсь, но эта конструкция выглядит слишком «программистской», возможно стоило переименовать
Рекомендуемая конструкция по установки env var в райнтайме (подразумевая «простоту» установки):
Когда писал свой github actions, обнаружил что job context и данные из Job API для нее же немного различаются: например, поле name. Какое-то взято из поля name в yml, какое-то из имени самого файла ¯\_(ツ)_/¯
Для pull request в job context сообщение коммита всегда зафиксирована (Merge from «branch1» to «branch2»), т.е. если ваш коллега будет коммитить в открытый пуллреквест, вы так и получите одно и тоже сообщение в уведомлении. Сообщение последнего коммита можно таки получить из Job API, но не все разработчики actions для уведомлений это делают
уведомления (slack, email, teams). Если в jenkins pipeline можно настроить post step, в bitbucket pipelines — post, то здесь уведомление это один из шагов. Будьте любезны не забыть if: always() если хотите чтобы уведомление пришло в случае ошибки или отмены
для тех кто пишет свой actions: лично для меня было квестом определить во время job run, процесс завершился с ошибкой или нет? Как я понял, есть два способа понять, из step context.conclusion или Job API. Оба как я понял, eventually consistent, т.е. даже если вы запросите текущий статус, не факт что актуальное значение будет известно на текущий момент. Т.е. если повезет получите success/failed, а в худшем in_progress
Github Actions UI: странные решения по переходам в ссылках. Допустим есть у вас коммит с failed status, где-то в середине пулреквеста. Вы решили посмотреть что же там, наводите на failed status, вам предлагается перейти по ссылке для деталей. После перехода отображается детали самого последнего билда, а не того по которому вы переходили ¯\_(ツ)_/¯
Плюсы для меня:
Типовые сценарии добавляются буквально за минуты (автоподбор сценария в зависимости от исходного кода вообще пушка, надеюсь будет в будущем еще умнее)
Есть конвенция, где располагать файлы для workflows, i.e в папке .github/workflows. Унифицирует процесс для всех проектов использующих GA
Подробная документация как для использования, так и для создания новых actions
Много выбора github actions в marketplaces. Но тут как с npm пакетами, вполне может быть какой-то шлак, или автор может забросить в любой момент. Ищите значок Verified Creator, чаще они производят качественные и продуманные actions
Github — это Microsoft, и у них получилось удачно включить все их сервисы в Ms Teams (аналог слака). Так что я надеюсь на очень крутую интеграцию и с github в ближайшем будущем
Те мелочи, которые я перечислил, не смертельны, с ними вполне можно сносно существовать, просто они портят достаточно неплохое первое впечатление от продукта. Буду благодарен, если кто-то нашел решение с уведомлениями. Спасибо
Нет, это заблуждение. Cloud agnostic это если бы вы просто поменяли provider: aws на что-то другое и у вас все заработает. Но нет, при смене облака, вам придется переписать все.
Terraform вам дает лишь hcl (hashicorp configuration language), т.е. да не придется учить другой язык, но все равно придется изучить ньюансы другого облака, термины и как все это написать под другой провайдер. Правильный термин — multiple cloud support
Недавно перешел с Appveyor на Azure Devops. Поэтому буду сравнивать с ним.
Из текущего негативного:
Много UI в preview, так как они переделывают его, часть функций должна выполняться в script секции, часть в старых tasks
Документация с неточностями, но, подумав головой, все решается. На замечания к документации на github issues реагируют достаточно оперативно
Субъективно, но мне не хватает некоторых predefined variables: индивидуальный номер билда на каждый build pipeline, название ветки для пуллреквеста вместо просто merge, etc
Ценовая политика: платишь за машину для сборки + за каждого пользователя. Да, там есть бесплатные 1800 минут и 5 пользователей, но если сборки часто и команда большая, то лимит на пользователей/минуты довольно быстро исчерпывается
Из позитива:
Довольно удачная на мой взгляд структура: builds pipeline, artefacts, release pipeline, approves, которая позволяет сделать CI/CD в кратчайшие сроки
Предоставляют self-hosted build agent, либо azure hosted
Несмотря на негативные моменты, продолжаем есть кактус пользоваться уже можно, но если у вас уже есть CI/CD система, я бы не торопился менять
Я обычно оставляю отзывы на прошедшие собеседования на glassdoor. Обычно ставлю негативную оценку если не было обратной связи с уточнением почему (искренне надеюсь, что компании научатся давать фидбек)
В дженкинсе меня лично жутко раздражает UI. Пробовал Blue Ocean, выглядит неплохо, но постоянные переходы на старый UI там, где недоделано, портит все впечатление.
А мобильное приложение у вас взаимодействует с самим трекером напрямую? Или же только с бэкендом и уже дальше бэкенд с трекером?
Что насчет Rancher Desktop?
Вы не поняли, идея (пока в виде предложения от депутата)
оформить подпискусобирать с работодателя дополнительную плату (1200 SGD) за иностранца в штате каждый месяц, чтобы мотивировать нанимать местных. Никакого возврата как в случае отказа с PR не будет.PsyHaSTe подскажите, а у вас работает intelli sense в IDE/text editor с sqlx макросами (да и вообще с макросами)? Я пробовал пару раз sqlx (у самого IDEA c Rust плагином), но как только дописываю ключевое слово макроса на этом помощь IDE заканчивается.
Нужно смотреть условия в контракте. Там вполне может быть что-то типа такого: все права на разработанное ПО в течение трудоустройства принадлежит работодателю.
Вставлю свои пять копеек, мы используем у себя частично (есть также jenkins, и совсем немного bibtucket pipelines).
Так вот, github actions все еще страдает мелочными проблемами, даже несмотря на версию v2.
Список досадных мелочей и проблем, с которыми я встретился:
Плюсы для меня:
Те мелочи, которые я перечислил, не смертельны, с ними вполне можно сносно существовать, просто они портят достаточно неплохое первое впечатление от продукта. Буду благодарен, если кто-то нашел решение с уведомлениями. Спасибо
Нет, это заблуждение. Cloud agnostic это если бы вы просто поменяли provider: aws на что-то другое и у вас все заработает. Но нет, при смене облака, вам придется переписать все.
Terraform вам дает лишь hcl (hashicorp configuration language), т.е. да не придется учить другой язык, но все равно придется изучить ньюансы другого облака, термины и как все это написать под другой провайдер. Правильный термин — multiple cloud support
dotnet fsidevblogs.microsoft.com/dotnet/announcing-f-4-7
Из текущего негативного:
Из позитива:
Несмотря на негативные моменты,
продолжаем есть кактуспользоваться уже можно, но если у вас уже есть CI/CD система, я бы не торопился менятьНесмотря на удаление баз