O GitHub Actions \u00e9 uma ferramenta integrada no GitHub que permite automatizar tarefas como testes, builds e deploys. A grande vantagem \u00e9 que tudo acontece dentro do pr\u00f3prio reposit\u00f3rio, sem necessidade de configurar servidores externos ou instalar ferramentas adicionais. Com alguns ficheiros YAML, consegues criar pipelines de integra\u00e7\u00e3o e entrega cont\u00ednua que garantem qualidade e consist\u00eancia no teu c\u00f3digo.<\/p>\n\n\n\n
Para come\u00e7ar, \u00e9 preciso criar a pasta Depois de configurar o workflow, basta ir \u00e0 aba Actions<\/strong> no GitHub para acompanhar a execu\u00e7\u00e3o. Ali encontras todos os workflows que correram, com logs detalhados de cada passo. Se algo falhar, os logs ajudam a identificar rapidamente o problema. Esta visibilidade \u00e9 fundamental para perceber se o pipeline est\u00e1 a funcionar como esperado.<\/p>\n\n\n\n \u00c0 medida que o projeto cresce, podes expandir o workflow para incluir mais tarefas. \u00c9 comum adicionar linting para verificar a qualidade do c\u00f3digo, criar builds antes de correr testes ou configurar deploys autom\u00e1ticos para staging e produ\u00e7\u00e3o. Tamb\u00e9m \u00e9 poss\u00edvel agendar workflows para correr em hor\u00e1rios fixos, como por exemplo todos os dias \u00e0 meia-noite, usando a sintaxe de cron. Esta flexibilidade permite adaptar o GitHub Actions \u00e0s necessidades espec\u00edficas de cada equipa ou projeto.<\/p>\n\n\n\n Em resumo, o GitHub Actions \u00e9 uma forma r\u00e1pida e pr\u00e1tica de automatizar o ciclo de desenvolvimento. Com apenas um ficheiro YAML, consegues garantir que o c\u00f3digo \u00e9 testado e preparado sempre que algu\u00e9m faz altera\u00e7\u00f5es. E \u00e0 medida que o projeto evolui, podes escalar para pipelines mais complexos que cobrem todo o ciclo de vida da aplica\u00e7\u00e3o, desde a valida\u00e7\u00e3o inicial at\u00e9 ao deploy final. Este \u00e9 um ficheiro inicial que podes copiar para usar nos teus projectos e por sua vez evoluir ao longo do tempo. Neste momento apenas temos integra\u00e7\u00e3o cont\u00ednua (CI), no futuro vamos incluir a entrega cont\u00ednua (CD), mas primeiro vamos configurar um local runner para poder publicar o projecto localmente.<\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" O GitHub Actions \u00e9 uma ferramenta integrada no GitHub que permite automatizar tarefas como testes, builds e deploys. A grande vantagem \u00e9 que tudo acontece dentro do pr\u00f3prio reposit\u00f3rio, sem necessidade de configurar servidores externos ou instalar ferramentas adicionais. Com alguns ficheiros YAML, consegues criar pipelines de integra\u00e7\u00e3o e entrega cont\u00ednua que garantem qualidade e…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-273","post","type-post","status-publish","format-standard","hentry","category-sem-categoria"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t.github\/workflows<\/code> no reposit\u00f3rio. Dentro dessa pasta ficam os ficheiros que descrevem os workflows. Cada workflow \u00e9 escrito em YAML e define tr\u00eas coisas principais: quando deve correr, o que deve fazer e como deve executar cada passo. Os eventos determinam quando o workflow \u00e9 disparado, por exemplo, sempre que h\u00e1 um push<\/em> ou um pull request<\/em>. Os jobs agrupam tarefas que podem correr em paralelo ou em sequ\u00eancia. E dentro de cada job, os steps descrevem comandos ou a\u00e7\u00f5es individuais.<\/p>\n\n\n\nCriar o Primeiro Workflow<\/h3>\n\n\n\n
\n
.github\/workflows<\/code>.<\/li>\n\n\n\nci.yml<\/code>.<\/li>\n\n\n\n# This workflow will build a .NET project\n# For more information see: https:\/\/docs.github.com\/en\/actions\/automating-builds-and-tests\/building-and-testing-net\n\nname: .NET\n\non:\n push:\n branches: [ \"main\" ]\n pull_request:\n branches: [ \"main\" ]\n\njobs:\n build:\n runs-on: ubuntu-latest\n\n steps:\n - uses: actions\/checkout@v4\n\n - name: Setup .NET\n uses: actions\/setup-dotnet@v4\n with:\n dotnet-version: '8.0.x'\n\n - name: Restore dependencies\n run: dotnet restore\n\n - name: Build\n run: dotnet build --configuration Release --no-restore\n\n - name: Test\n run: dotnet test --configuration Release --verbosity normal<\/code><\/pre>\n\n\n\nPassos do job<\/h3>\n\n\n\n
\n
actions\/checkout@v4<\/code> para trazer o conte\u00fado do reposit\u00f3rio para dentro da m\u00e1quina virtual. Sem isto, n\u00e3o haveria acesso ao c\u00f3digo.<\/li>\n\n\n\nactions\/setup-dotnet@v4<\/code>. Isto garante que os comandos dotnet<\/code> v\u00e3o funcionar com a vers\u00e3o correta.<\/li>\n\n\n\ndotnet restore<\/code>, que baixa e prepara todas as bibliotecas necess\u00e1rias definidas nos ficheiros .csproj<\/code> ou .sln<\/code>.<\/li>\n\n\n\ndotnet build --configuration Release --no-restore<\/code>. Isto compila o projeto em modo Release, mas sem restaurar depend\u00eancias novamente (porque j\u00e1 foram restauradas no passo anterior).<\/li>\n\n\n\ndotnet test --configuration Release --verbosity normal<\/code>. Isto executa todos os testes definidos na solu\u00e7\u00e3o Zesty.sln<\/code>, tamb\u00e9m em modo Release, e mostra os resultados com detalhe normal.<\/li>\n<\/ol>\n\n\n\nConclus\u00e3o<\/h3>\n\n\n\n