Title: Desenvolvimento de Software / GitHub Actions
Tags: Desenvolvimento_de_Software Resumo
On every note of this deck, unless a note says otherwise:
tldr: - GitHub Actions é a ferramenta nativa de CI/CD do GitHub, que automatiza testes, build e deploy sem precisar executar tudo “na mão”.
- Conecta-se diretamente à cultura DevOps:
- CI: em push ou pull request, roda testes automaticamente e alerta se quebrar.
- CD: se passar, pode empacotar (Docker/.zip) e fazer deploy em ambientes (teste/produção).
- Diferença importante:
- Actions: automação de workflows, execução efêmera em runners, definida por YAML no repositório.
- GitHub Apps: extensões “tipo plugin”, persistentes, rodando em servidor próprio e reagindo a eventos.
- Onde fica o workflow: arquivos .yml/.yaml devem estar em /.github/workflows/ (diferente do GitLab, que usa .gitlab-ci.yml na raiz).
- Estrutura básica:
- Um workflow tem 1+ jobs; por padrão, jobs rodam em paralelo.
- Para executar em sequência, use needs: (ex.: deploy depende de test).
- Execução ocorre em um runner definido por runs-on::
- GitHub-hosted (ex.: ubuntu-latest)
- Self-hosted (máquinas próprias)
- Principais chaves YAML: name, on, jobs, <job_id>, needs, runs-on, steps, uses, run, env.
- uses: actions/checkout@v3 é crucial para baixar o código no runner (ele começa “vazio”).
- Indentação no YAML é crítica: define hierarquia (jobs, steps etc.).
link: https://documentacao.online/estudos/fevt.html

front: (Ano: 2025 Banca: CESPE / CEBRASPE Órgão: PC-DF Prova: CESPE / CEBRASPE - 2025 - PC- DF - Gestor de Apoio as Atividades Policiais Civis - Especialidade: Analista de Informática: Desenvolvimento de Sistemas) A respeito de gerência de configuração de software, julgue o item subsecutivo. A integração contínua no GitHub Actions é configurada manualmente em cada repositório, e os workflows são executados apenas quando o código é aprovado por uma revisão de código.
response: Errado
comment: "configurada manualmente em cada repositório": Isso está CORRETO. Você (ou alguém da equipe) precisa criar o arquivo YAML (ex: ci.yml) dentro da pasta .github/workflows do repositório. Não é automático. "executados APENAS quando o código é aprovado por uma revisão de código": Aqui está o erro grosseiro! Como vimos na sintaxe, o gatilho (o on:) é super flexível. Ele pode rodar on: push (qualquer envio de código), on: pull_request (qualquer abertura de PR, antes da aprovação), on: schedule (de tempos em tempos), on: workflow_dispatch (manualmente) e muitos outros. A banca restringiu demais o gatilho, tornando o item errado.
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - "configurada manualmente em cada repositório": Isso está CORRETO. Você (ou alguém da equipe) precisa criar o arquivo YAML (ex: ci.yml) dentro da pasta .github/workflows do repositório. Não é automático. "executados APENAS quando o código é aprovado por uma revisão de código": Aqui está o erro grosseiro! Como vimos na sintaxe, o gatilho (o on:) é super flexível. Ele pode rodar on: push (qualquer envio de código), on: pull_request (qualquer abertura de PR, antes da aprovação), on: schedule (de tempos em tempos), on: workflow_dispatch (manualmente) e muitos outros. A banca restringiu demais o gatilho, tornando o item errado.

front: (Ano: 2025 Banca: CESPE / CEBRASPE Órgão: TRF - 6ª REGIÃO Prova: CESPE / CEBRASPE - 2025 - TRF - 6ª REGIÃO - Analista Judiciário – Área: Apoio Especializado – Especialidade: Análise de Sistemas de Informação)
steps: - name: Checkout code
- uses: actions/checkout@v2
Com base na instrução precedente, julgue o item a seguir, considerando o contexto de um arquivo de workflow no GitHub Actions e a função da ação actions/checkout@v2. A instrução apresentada tem como objetivo realizar o checkout, ou seja, baixar o código do repositório no runner para a execução de outras tarefas.
response: Certo
comment: Perfeito! o seguinte: quando o GitHub Actions começa a rodar um job, ele usa uma máquina virtual (o runner) "limpa". Essa máquina não tem o seu código. O primeiro passo de quase todo workflow de CI/CD é, portanto, "fazer o checkout", que é um jargão para dizer "baixar o código-fonte do repositório para dentro do runner". É exatamente isso que a action actions/checkout@v2 (ou v3, v4...) faz. Sem ela, os passos seguintes (como run: npm test) não encontrariam os arquivos do projeto.
title: GitHub Actions
Other fields (not shown on cards):
back: Certo - Perfeito! o seguinte: quando o GitHub Actions começa a rodar um job, ele usa uma máquina virtual (o runner) "limpa". Essa máquina não tem o seu código. O primeiro passo de quase todo workflow de CI/CD é, portanto, "fazer o checkout", que é um jargão para dizer "baixar o código-fonte do repositório para dentro do runner". É exatamente isso que a action actions/checkout@v2 (ou v3, v4...) faz. Sem ela, os passos seguintes (como run: npm test) não encontrariam os arquivos do projeto.

front: (Ano: 2023 Banca: FUNDATEC Órgão: PROCERGS Prova: FUNDATEC - 2023 - PROCERGS - ANC - Analista em Computação - Ênfase em Negócios de Produtos e Serviços de TI) No projeto em que você começará a trabalhar, você precisará de quatro engenheiros ............. para programar o back-end (server) e front-end (client) da aplicação web. Além disso, precisará de mais um ............. para automatizar o deploy e a integração contínua da aplicação que será toda em AWS e GitHub Actions. Assinale a alternativa que preenche, correta e respectivamente, as lacunas do trecho acima.
A) full-stack – engenheiro de dados
B) full-stack – engenheiro DevOps
C) de dados – analista de infraestrutura
D) de dados – engenheiro DevOps
E) full-stack – analisa de infraestrutura
response: Alternativa B
comment: Questão simples, mas serve para fixar que o GitHub Actions é uma ferramenta de integração contínua e está associada às práticas DevOps. Quanto à primeira parte, foge um pouco do escopo da aula, mas era necessário saber que um engenheiro que programa back-end + front-end é o engenheiro full-stack.
title: GitHub Actions
Other fields (not shown on cards):
back: Alternativa B - Questão simples, mas serve para fixar que o GitHub Actions é uma ferramenta de integração contínua e está associada às práticas DevOps. Quanto à primeira parte, foge um pouco do escopo da aula, mas era necessário saber que um engenheiro que programa back-end + front-end é o engenheiro full-stack.

front: (Ano: 2024 Banca: FCC Órgão: TRT - 20ª REGIÃO (SE) Prova: FCC - 2024 - TRT - 20ª REGIÃO (SE) - Analista Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação) Uma equipe deseja adotar abordagem DevOps para automatizar o processo de integração e entrega contínua (CI/CD). Para isso, é necessário integrar diversas ferramentas para otimizar a automação dos testes e a entrega do produto. Dentre essas ferramentas, encontra-se o:
A) Selenium, que é utilizado para automação de builds, testes de integração e execução de pipelines de CI/CD, que integra-se ao CircleCl, que faz a gestão de repositórios Git. O CircleCl é compatível apenas com as linguagens Go, Java e Ruby, apresentando incompatibilidade com Python, Ruby Scala, Node js, PHP e Haskell.
B) Git Esta ferramenta precisa ser integrada ao GitHub, uma vez que são interdependentes. Usadas em conjunto, conseguem realizar o controle de versão e proporcionar a integração continua.
C) GitHub Actions, que permite a criação de workflows de CI/CD diretamente no GitHub. Os workflows são definidos no diretório .github/workflows de um repositório, que pode ter vários workflows, cada um dos quais podendo executar um conjunto diferente de tarefas, como criar e testar pull requests.
D) Jenkins, que é uma ferramenta escrita em PHP, exclusiva para automação de testes, que integra- se ao Git para armazenar o histórico dos testes automatizados executados.
E) Maven, que é uma ferramenta proprietária para automação de builds, que também possui capacidades nativas de controle de versões e pipelines de CI/CD, similar ao Gittab CI/CD. Um projeto Maven fica atrelado a um arquivo principal: o pom.java.
response: Alternativa C
comment: A letra C é uma definição de livro sobre o que é o GitHub Actions. Vamos "destrinchar" por que ela está 100% correta: "permite a criação de workflows de CI/CD diretamente no GitHub": Ela é, de fato, a ferramenta nativa do GitHub para isso. "definidos no diretório .github/workflows": É o caminho exato onde os arquivos .yml devem ficar. "pode ter vários workflows": Sim, você pode ter ci.yml, deploy-prod.yml, security-scan.yml, etc. "executar um conjunto diferente de tarefas": Sim, cada workflow tem seus próprios jobs e steps. "como criar e testar pull requests": Correto, on: pull_request é um dos gatilhos mais comuns. A alternativa C é um resumo perfeito do que estudamos. As outras estão erradas por motivos que fogem do escopo da aula (Jenkins não é escrito em PHP; Git e GitHub não são interdependentes; Selenium é para testes de UI, não builds; Maven usa pom.xml, não pom.java).
title: GitHub Actions
Other fields (not shown on cards):
back: Alternativa C - A letra C é uma definição de livro sobre o que é o GitHub Actions. Vamos "destrinchar" por que ela está 100% correta: "permite a criação de workflows de CI/CD diretamente no GitHub": Ela é, de fato, a ferramenta nativa do GitHub para isso. "definidos no diretório .github/workflows": É o caminho exato onde os arquivos .yml devem ficar. "pode ter vários workflows": Sim, você pode ter ci.yml, deploy-prod.yml, security-scan.yml, etc. "executar um conjunto diferente de tarefas": Sim, cada workflow tem seus próprios jobs e steps. "como criar e testar pull requests": Correto, on: pull_request é um dos gatilhos mais comuns. A alternativa C é um resumo perfeito do que estudamos. As outras estão erradas por motivos que fogem do escopo da aula (Jenkins não é escrito em PHP; Git e GitHub não são interdependentes; Selenium é para testes de UI, não builds; Maven usa pom.xml, não pom.java).

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Os arquivos de workflow do GitHub Actions são scripts de shell (bash) que devem ser armazenados em um diretório chamado .github/config na raiz do repositório para serem executados.
response: Errado
comment: O GitHub Actions realmente usa arquivos na pasta .github, mas a subpasta correta é workflows. E o mais importante: os arquivos não são scripts de shell, eles são escritos em YAML.
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - O GitHub Actions realmente usa arquivos na pasta .github, mas a subpasta correta é workflows. E o mais importante: os arquivos não são scripts de shell, eles são escritos em YAML.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Em um workflow, a palavra-chave “uses” é utilizada para executar comandos de script diretamente no runner, como npm install, enquanto a palavra-chave run é usada para chamar Actions reutilizáveis, como actions/checkout@v3.
response: Errado
comment: É o contrário, galera. run é para rodar comandos de shell (ex: run: npm install). uses é para "usar" uma Action pronta (ex: uses: actions/checkout@v3).
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - É o contrário, galera. run é para rodar comandos de shell (ex: run: npm install). uses é para "usar" uma Action pronta (ex: uses: actions/checkout@v3).

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Uma equipe deseja automatizar seus processos de CI/CD. Eles precisam de uma solução que rode testes em máquinas virtuais limpas (runners) toda vez que um pull request for aberto. A solução nativa do GitHub para essa finalidade, definida por arquivos YAML, é o:
A) GitHub Apps
B) GitHub Runners
C) Jenkins
D) GitHub Actions
E) GitHub Pages
response: Alternativa D
comment: Essa é a definição perfeita do GitHub Actions (D). Ele é a ferramenta nativa de CI/CD, roda em runners e é definida por YAML. (A) GitHub Apps serve para estender o GitHub, não para CI/CD. (B) GitHub Runners é lhufas. (C) Jenkins é uma ferramenta de CI/CD, mas não é nativa do GitHub. (E) GitHub Pages serve para criar websites gratuitamente a partir de repositórios do GitHub.
title: GitHub Actions
Other fields (not shown on cards):
back: Alternativa D - Essa é a definição perfeita do GitHub Actions (D). Ele é a ferramenta nativa de CI/CD, roda em runners e é definida por YAML. (A) GitHub Apps serve para estender o GitHub, não para CI/CD. (B) GitHub Runners é lhufas. (C) Jenkins é uma ferramenta de CI/CD, mas não é nativa do GitHub. (E) GitHub Pages serve para criar websites gratuitamente a partir de repositórios do GitHub.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) O GitHub Actions permite apenas a utilização de runners hospedados pelo próprio GitHub (GitHub-hosted runners), não sendo possível configurar e utilizar máquinas próprias (self-hosted runners) para a execução dos jobs.
response: Errado
comment: O GitHub Actions é flexível! Você pode usar os runners do GitHub (GitHub-hosted), que são mais fáceis, ou pode configurar seus próprios servidores (self-hosted runners), o que é comum em empresas que precisam de hardware específico ou mais segurança de rede.
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - O GitHub Actions é flexível! Você pode usar os runners do GitHub (GitHub-hosted), que são mais fáceis, ou pode configurar seus próprios servidores (self-hosted runners), o que é comum em empresas que precisam de hardware específico ou mais segurança de rede.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Por padrão, se um workflow define múltiplos jobs (ex: job-A, job-B, job-C) no mesmo nível, eles serão executados sequencialmente, onde job-B só iniciará após job-A terminar, e job-C após job-B.
response: Errado
comment: O padrão do GitHub Actions é a paralelização. Se você definir vários jobs, eles vão rodar todos ao mesmo tempo (em paralelo) para terminar mais rápido. Se você quiser que eles rodem em sequência, você precisa forçar isso usando a sintaxe needs: .
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - O padrão do GitHub Actions é a paralelização. Se você definir vários jobs, eles vão rodar todos ao mesmo tempo (em paralelo) para terminar mais rápido. Se você quiser que eles rodem em sequência, você precisa forçar isso usando a sintaxe needs: .

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) No contexto da sintaxe de um workflow, a palavra-chave “on” é utilizada para:
A) Definir as variáveis de ambiente que o job utilizará.
B) Definir qual Action reutilizável será executada.
C) Definir o sistema operacional do runner (ex: ubuntu-latest).
D) Definir os comandos de shell que serão executados.
E) Definir o evento (ou eventos) que disparará o workflow.
response: Alternativa E
comment: Pessoal, o on é o "gatilho" (trigger). É ele que diz ao GitHub: "Ei, fique atento! Quando (on) acontecer um push ou um pull_request, rode este workflow". As outras opções são: (A) env, (B) uses, (C) runs-on, (D) run.
title: GitHub Actions
Other fields (not shown on cards):
back: Alternativa E - Pessoal, o on é o "gatilho" (trigger). É ele que diz ao GitHub: "Ei, fique atento! Quando (on) acontecer um push ou um pull_request, rode este workflow". As outras opções são: (A) env, (B) uses, (C) runs-on, (D) run.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) GitHub Actions e GitHub Apps são ferramentas com propósitos distintos. Actions foca na automação de workflows (CI/CD) e é efêmero (roda e termina), enquanto Apps são extensões persistentes que rodam em servidores próprios (do usuário) para estender a funcionalidade do GitHub.
response: Certo
comment: Actions = Automação de CI/CD, efêmero, roda em runners. Apps = Extensão do GitHub, persistente, roda no seu servidor. A assertiva está 100% correta.
title: GitHub Actions
Other fields (not shown on cards):
back: Certo - Actions = Automação de CI/CD, efêmero, roda em runners. Apps = Extensão do GitHub, persistente, roda no seu servidor. A assertiva está 100% correta.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) A action actions/checkout@v3 (ou versões similares) é um passo opcional, pois o runner onde o job executa já possui, por padrão, uma cópia completa do código do repositório.
response: Errado
comment: Pelo contrário, é o passo fundamental e quase sempre o primeiro! O runner é uma máquina virtual limpa. Ela não tem seu código. O actions/checkout é o comando que "baixa" (faz o checkout) do seu código para dentro do runner, para que os passos seguintes (como run: npm test) possam funcionar.
title: GitHub Actions
Other fields (not shown on cards):
back: Errado - Pelo contrário, é o passo fundamental e quase sempre o primeiro! O runner é uma máquina virtual limpa. Ela não tem seu código. O actions/checkout é o comando que "baixa" (faz o checkout) do seu código para dentro do runner, para que os passos seguintes (como run: npm test) possam funcionar.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Em um job, para forçar que o job deploy só seja executado após a conclusão bem-sucedida do job test, qual a sintaxe correta a ser usada dentro da definição do job deploy?
A) requires: test
B) depends-on: test
C) needs: test
D) after: test
E) run-after: test
response: C
comment: Sintaxe pura! Para criar uma dependência entre jobs (fazendo com que rodem em sequência), a palavra-chave correta é needs:. As outras opções são "pegadinhas" que parecem lógicas, mas estão sintaticamente incorretas.
title: GitHub Actions
Other fields (not shown on cards):
back: C - Sintaxe pura! Para criar uma dependência entre jobs (fazendo com que rodem em sequência), a palavra-chave correta é needs:. As outras opções são "pegadinhas" que parecem lógicas, mas estão sintaticamente incorretas.

front: (PROF. VINICIUS BORGES / INÉDITA - 2025) Um desenvolvedor precisa executar um workflow em dois cenários distintos: 1) Quando um push for feito para a branch main ou 2) Quando um pull_request for aberto para a branch main. Qual sintaxe on atende a esse requisito?
A) on: { push: { branches: [ main ] }, pull_request: { branches: [ main ] } }
B) on: [push(main), pull_request(main)]
C) on: push OR pull_request
D) on: event: push(main) AND event: pull_request(main)
E) on: (push && main) || (pull_request && main)
response: Alternativa A
comment: A forma correta de aplicar filtros (como o nome de uma branch) a um evento (como push ou pull_request) é usando essa estrutura de "mapa" (chave-valor) do YAML. A opção (A) é a única sintaticamente válida e que atende aos dois requisitos.
title: GitHub Actions
Other fields (not shown on cards):
back: Alternativa A - A forma correta de aplicar filtros (como o nome de uma branch) a um evento (como push ou pull_request) é usando essa estrutura de "mapa" (chave-valor) do YAML. A opção (A) é a única sintaticamente válida e que atende aos dois requisitos.