{"id":273,"date":"2025-11-29T21:01:49","date_gmt":"2025-11-29T21:01:49","guid":{"rendered":"https:\/\/codefornoobs.pt\/?p=273"},"modified":"2025-11-29T21:01:50","modified_gmt":"2025-11-29T21:01:50","slug":"como-configurar-e-correr-github-actions","status":"publish","type":"post","link":"https:\/\/codefornoobs.pt\/?p=273","title":{"rendered":"Como Configurar e Correr GitHub Actions"},"content":{"rendered":"\n<p>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<p>Para come\u00e7ar, \u00e9 preciso criar a pasta <code>.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 <em>push<\/em> ou um <em>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\n<h3 class=\"wp-block-heading\">Criar o Primeiro Workflow<\/h3>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>No reposit\u00f3rio, cria a pasta <code>.github\/workflows<\/code>.<\/li>\n\n\n\n<li>Adiciona um ficheiro, por exemplo <code>ci.yml<\/code>.<\/li>\n\n\n\n<li>Define o conte\u00fado do workflow.<\/li>\n<\/ol>\n\n\n\n<pre class=\"wp-block-code\"><code># 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: &#91; \"main\" ]\n  pull_request:\n    branches: &#91; \"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\n<h3 class=\"wp-block-heading\">Passos do job<\/h3>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li><strong>Checkout do c\u00f3digo.<\/strong> Usa a a\u00e7\u00e3o <code>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\n<li><strong>Setup .NET<\/strong> Configura o ambiente .NET com a vers\u00e3o <strong>8.0.x<\/strong> usando <code>actions\/setup-dotnet@v4<\/code>. Isto garante que os comandos <code>dotnet<\/code> v\u00e3o funcionar com a vers\u00e3o correta.<\/li>\n\n\n\n<li><strong>Restaurar depend\u00eancias<\/strong> Corre <code>dotnet restore<\/code>, que baixa e prepara todas as bibliotecas necess\u00e1rias definidas nos ficheiros <code>.csproj<\/code> ou <code>.sln<\/code>.<\/li>\n\n\n\n<li><strong>Build da solu\u00e7\u00e3o<\/strong> Executa <code>dotnet 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\n<li><strong>Testes<\/strong> Finalmente, corre <code>dotnet test --configuration Release --verbosity normal<\/code>. Isto executa todos os testes definidos na solu\u00e7\u00e3o <code>Zesty.sln<\/code>, tamb\u00e9m em modo Release, e mostra os resultados com detalhe normal.<\/li>\n<\/ol>\n\n\n\n<p>Depois de configurar o workflow, basta ir \u00e0 aba <strong>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<p>\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<h3 class=\"wp-block-heading\">Conclus\u00e3o<\/h3>\n\n\n\n<p>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><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8230;<\/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,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-273","post","type-post","status-publish","format-standard","hentry","category-sem-categoria"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/posts\/273","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=273"}],"version-history":[{"count":2,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/posts\/273\/revisions"}],"predecessor-version":[{"id":275,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=\/wp\/v2\/posts\/273\/revisions\/275"}],"wp:attachment":[{"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=273"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=273"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/codefornoobs.pt\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=273"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}