Из этого краткого руководства вы узнаете, как создать рабочий процесс GitHub для проверки компиляции исходного кода .NET в GitHub. Компиляция кода .NET является одним из самых простых шагов проверки, которые можно выполнить для обеспечения качества обновлений кода. Если код не компилируется (или не выполняет сборку), это простое средство сдерживания и должно быть четким признаком того, что код необходимо исправить.
Предварительные требования
- Учетная запись GitHub.
- Репозиторий исходного кода .NET.
Создание файла рабочего процесса
В репозитории GitHub добавьте новый YAML-файл в каталог .github/workflows . Выберите понятное имя файла, которое будет четко указывать на назначение рабочего процесса. Дополнительные сведения см. в разделе Файл рабочего процесса.
GitHub требует, чтобы файлы композиции рабочего процесса размещались в каталоге .github/workflows .
Файлы рабочего процесса обычно определяют композицию одного или нескольких действий GitHub с помощью jobs./steps[*] . Дополнительные сведения см. в статье Синтаксис рабочего процесса для GitHub Actions.
5 причин научиться собирать софт из исходников
Создайте файл с именем build-validation.yml, скопируйте и вставьте в него следующее содержимое YML:
В предыдущей композиции рабочего процесса:
-
Определяет name: build имя , «сборка» будет отображаться в индикаторах состояния рабочего процесса.
name: build
on: push: pull_request: branches: [ main ] paths: — ‘**.cs’ — ‘**.csproj’
- Активируется при push возникновении или pull_request в main ветви, в которой все файлы изменяются с расширением CS или CSPROJ .
env: DOTNET_VERSION: ‘6.0.401’ # The .NET SDK version to use
— name: Install WASM Tools Workload run: dotnet workload install wasm-tools
Дополнительные сведения о рабочих нагрузках .NET см. в разделе dotnet workload install .
В этом случае файл рабочего процесса можно рассматривать как композицию, представляющую различные этапы создания приложения. Доступно множество команд .NET CLI , большинство из которых можно использовать в контексте действия GitHub.
Создание индикатора состояния рабочего процесса
Обычно репозитории GitHub имеют файл README.md в корне каталога репозитория. Кроме того, приятно сообщать о последнем состоянии для различных рабочих процессов. Все рабочие процессы могут создавать эмблемы состояния, которые визуально привлекательны в файле README.md . Чтобы добавить индикатор состояния рабочего процесса, выполните следующие действия:
- В репозитории GitHub выберите параметр навигации Действия .
- Все рабочие процессы репозитория отображаются слева, выберите нужный рабочий процесс и нажмите кнопку с многоточием (. ).
- Кнопка с многоточием (. ) расширяет параметры меню для выбранного рабочего процесса.
- Выберите пункт меню Создать индикатор состояния .
- Нажмите кнопку Копировать индикатор состояния Markdown .
- Вставьте Markdown в файл README.md , сохраните файл, зафиксируйте и отправьте изменения.
Научись Linux: сборка программ из исходников (эпизод 13)
Пример индикатора состояния рабочего процесса сборки
См. также раздел
- dotnet restore
- dotnet build
- действия/извлечение
- actions/setup-dotnet
Источник: learn.microsoft.com
Кросс-платформенная сборка с GitHub Actions
Если проект живет на GitHub, можно за десять минут настроить авто-сборку под основные операционные системы — Windows, Linux и macOS.
Раньше для сборки почти всегда использовали Travis CI, многие по инерции и сейчас так делают. Но есть способ лучше — GitHub Actions.
GitHub Actions — невероятно мощный бесплатный сервис автоматизации любых задач. Грубо говоря, вы выполняете свой код на серверах Гитхаба и делаете там все, что заблагорассудится. Звучит диковато, но открывает бездну возможностей. В том числе — автоматическую сборку проекта под все ОС. Особенно приятно, что можно собирать под Windows.
Вот как это работает:
- Создаете файл конфигурации.
mkdir -p .github/workflows touch .github/workflows/build.yml
- Указываете условия запуска сборки.
Например, собирать при каждом коммите:
on: push
Или только из новых тегов:
on: push: tags: — «*»
- Перечисляете операционные системы.
runs-on: $> strategy: matrix: include: — os: ubuntu-latest — os: windows-latest — os: macos-latest
- Указываете шаги сборки.
Действие actions/checkout скачивает исходники, а на остальных шагах выполняются те команды, что указаны по тексту. В примере это сборка исходного кода на C с помощью gcc , но у вашего проекта может быть npm run для JS или tox для Python — то, что обычно используете для сборки.
Если для вашего языка есть стандартный репозиторий пакетов вроде npm или pypi — здесь же можно опубликовать сборку. Если репозитория нет, можно опубликовать прямо на гитхабе с помощью действия svenstaro/upload-release-action :
- Полный пример конфигурации
- Коммитите изменения, пушите и наблюдаете результат на вкладке Actions репозитория на Гитхабе.
Готово! Теперь Гитхаб трудится, а вы отдыхаете.
- Документация по GitHub Actions
- Как сделать все что угодно вообще с GitHub Actions
Подписывайтесь на канал, чтобы не пропустить новые заметки
Источник: antonz.ru
Начинаем работать с git — пошаговая инструкция
Первые шаги в освоении мира компьютерных технологий пройдены, ты знаешь, зачем сюда пришёл, к чему стремишься, и как этого добиться, упорно учишься, переходя от курса к курсу. За спиной первые написанные программы и отловленные баги, а впереди маячат светлые перспективы коммерческой разработки программного обеспечения.
Наверное, пора узнать…
Секреты командной разработки
Разработка – это почти всегда командная игра. Пора учиться работать в команде.
Даже если пока что в твоей команде только монитор, системник (или старенький ноутбук) и острое желание стать программистом, всё равно пора учиться.
Программисту проще стать своим среди своих, ведь за него говорят не дежурные улыбки, перекуры и чаепития с печеньками, а чёткие строки кода, элегантные функции и безупречная работа готовых приложений.
Чтобы эффективно работать в команде, мало знать синтаксис языка, ключевые библиотеки и уметь обращаться с базами данных. Необходимо уметь работать в удобной для команды системе контроля версий.
О системах контроля версий их преимуществах и недостатках можно почитать здесь.
В этой статье мы перейдём от теории к практике и расскажем, как работать с git’ом.
Шаг 1. Выбираем git-хостинг
Git-хостинг на разных условиях предлагают десятки компаний.
Самые известные из них: Github, Sourceforge, Google Code, GitLab, Codebase. Выбери удобный интерфейс и регистрируйся на понравившемся хостинге.
В этой статье мы рассмотрим работу с git-хостингом на примере Github’а.
Шаг 2. Регистрация
Процедура регистрации на Гитхабе простая и интуитивно понятная даже для тех, чей уровень английского далёк от Upper Intermediate.
Логин, пароль, почта –> подтверждение, и связь с мировым сообществом программистов налажена.
Шаг 3. Создание репозитория
Ты можешь создать любое количество репозиториев, у каждого из которых будет issue tracking, wiki, условия для проведения code review и многое другое.
Политика разработчиков Github предполагает бесплатное использование хостинга для всех open-source проектов.
Чтобы создать новый репозиторий нажмём кнопку + в верхней части экрана и выберем New repository
Многие разработчики рано или поздно сталкиваются с необходимостью создания приватного репозитория, код из которого доступен только их команде. Для этих случаев на Github’е есть определённый тарифный план.
Но пока острой необходимости в создании приватного репозитория у нас нет, создадим обычный.
Жмём волшебную кнопку Create внизу экрана, и репозиторий готов.
Шаг 4. Работа с репозиторием
Работа с репозиторием может вестись из командной строки, напрямую из среды разработки или из графического интерфейса (git — клиент приложения).
Работа с графическим интерфейсом позволяет лучше понимать процессы, происходящие в локальном и удалённом репозитории. Поэтому я рекомендую начать работу с git с использованием графического интерфейса.
Шаг 5. Выбираем Гит-клиент
Потом, когда суть процессов изменения и обновления (восстановления) информации в репозитории станет для Вас очевидна, можно работать и через командную строку. В этом принципе работы есть немало своих преимуществ. Например, все новые опции Гитхаба реализуются сначала для использования в командной строке, и только потом адаптируются под графические интерфейсы.
Но вернёмся к git-клиентам.
Самыми популярными гит- клиентами на данный момент являются:
SmartGit
Удобное приложение гармонично сочетает все необходимые функции и доступную интуитивно понятную систему управления. SmartGit – один из самых удобных графических интерфейсов для профессиональной разработки. Некоммерческая разработка и разработка open-sourse проектов не требуют платной лицензии.
GitHub Desktop
«Родной» графический интерфейс Гитхаба. GitHub Desktop работает под Windows и Mac и практически полностью копирует функционал основного сайта. Работает под той же учётной записью.
Правда, не всегда оперативно справляется с большими программами.
Зато отлично подходит для начала работы с git.
GitKraken
Поддерживает GitHub, Bitbucket и Gitlab.
Кракен очень любят программисты – фрилансеры, которым периодически приходится менять команды, а значит, и условия командной разработки. Возможность работы с разными git-хостингами через привычное приложение со знакомым интерфейсом в таких случаях играет важную роль.
SourceTree
SourceTree позволяет работать с Bitbucket и GitHub. В приложении довольно простой интерфейс, подходящий, как для опытных программистов, так и для новичков.
Шаг 6. Работа со SmartGit
В этой статье мы рассмотрим работу с SmartGit.
Скачать SmartGit можно, например, отсюда:
Устанавливаем и запускаем.
Основные операции для работы с git
Clone
Первое, чему стоит научиться – это снимать копию проекта из удалённого репозитория в локальный.
Делается это довольно просто:
Затем копируем ссылку репозитория, созданного на Гитхабе (шаг 2)
Вставляем адрес удалённого репозитория в нужную ячейку в открывшемся окне, выбираем расположение нового локального репозитория у нас на компьютере, и получаем готовый локальный репозиторий.
К слову, аналогичным образом можно клонировать чужой открытый репозиторий и поближе познакомиться с чужим кодом.
Commit
Репозиторий готов – пора приступать к работе.
Написанный код мы помещаем в локальный репозиторий — папку .git (путь к которой мы указали в операции clone).
Если всё прошло успешно, в окошке SmartGit’а появится скопированный файл.
Для того чтобы зафиксировать изменения в локальном репозитории, нажимаем кнопку Commit.
В открывшемся окне пишем пояснительный комментарий к сохраняемому файлу и снова нажимаем кнопку Commit
Файл сохранён, а изменения внесены в журнал.
Push
Теперь заглянем на Github.com в наш удалённый репозиторий. Там до сих пор нет ни одного файла. Нужно срочно менять ситуацию.
Чтобы перенести изменения, внесённые в локальный репозиторий, в удалённый репозиторий, необходимо нажать кнопку Push.
К слову, отправить изменения в удалённый репозиторий, нам предлагают ещё в точке Commit’а
