Questão de Engenharia de Software — Github e Gitlab — CESPE / CEBRASPE 2026
Engenharia de Software›Github e Gitlab
Código
ce391134
Banca
CESPE / CEBRASPE
Órgão
TCU
Ano
2026
Cargo
AUFC ( )
Em relação a GitHub Actions, Grafana e DevSecOps, julgue o item a seguir.
O seguinte trecho do arquivo de workflow do GitHub Actions faz que o workflow seja acionado em duas situações distintas: quando uma nova etiqueta é criada no repositório e quando ocorre um push especificamente para a branch main.
01
on:
02
label:
03
types:
04
- created
05
page_build:
06
types:
07
- main
CCerto
EErrado
Revelar gabarito e comentário▾
GabaritoE — Errado
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
GitHub Actions: gatilhos de workflow (on: label e on: push)
Gabarito: Errado (E). O trecho de workflow apresentado está incorreto porque mistura, de forma inválida, a sintaxe de dois eventos distintos do GitHub Actions: o evento label (que usa types: [created]) e o evento push (que usa branches: [main]). No trecho, o evento page_build é usado de forma incorreta, e a configuração types: - main não é válida para o evento push, pois main deve ser especificada como uma branch, não como um tipo de atividade. A sintaxe correta para acionar o workflow em duas situações distintas seria usar on: [push, label] ou on: {push: {branches: [main]}, label: {types: [created]}}.
O GitHub Actions é a plataforma de automação de fluxos de trabalho (workflows) do GitHub. Um workflow é definido em um arquivo YAML (.github/workflows/*.yml) e é composto por eventos (o que dispara o workflow), jobs (o que será executado) e steps (os passos de cada job). O campo on (ou on:) é o coração do workflow: ele define quais eventos no repositório farão o workflow ser executado.
A sintaxe do campo on é flexível e pode ser usada de duas formas principais:
Lista simples de eventos: on: [push, pull_request] — o workflow é acionado por qualquer um dos eventos listados.
Configuração detalhada por evento: on: {push: {branches: [main]}, label: {types: [created]}} — permite filtrar cada evento com condições específicas (como branches, tipos de atividade, paths, etc.).
O evento push é disparado quando um commit é enviado (push) para o repositório. Para restringir a apenas uma branch específica, usa-se o filtro branches. O evento label é disparado quando uma etiqueta (label) é criada, editada ou removida no repositório, e o filtro types define qual tipo de atividade (created, edited, deleted) aciona o workflow.
O trecho do enunciado tenta configurar dois gatilhos: um para a criação de etiqueta (label com types: created) e outro para push na branch main. No entanto, a forma como foi escrita está errada. Vamos analisar linha por linha:
01 on: — inicia a definição dos eventos.
02 label: — define o evento label.
03 types: — inicia a lista de tipos de atividade para o evento label.
04 - created — adiciona o tipo created (criação de etiqueta). Até aqui, a sintaxe está correta.
05 page_build: — aqui está o primeiro erro. O evento page_build é um evento válido do GitHub Actions (disparado quando o GitHub Pages é construído), mas não é o evento push. O enunciado afirma que o workflow deve ser acionado por push na branch main, mas o trecho usa page_build em vez de push.
06 types: — repete a chave types, mas agora para o evento page_build.
07 - main — tenta usar main como um tipo de atividade, o que é inválido. Para o evento push, a branch deve ser especificada com branches: [main], não com types.
Portanto, o trecho não configura corretamente os dois gatilhos. Ele configura o evento label (corretamente) e o evento page_build (incorretamente, pois não é o evento push e a sintaxe types: - main é inválida).
A forma correta de escrever o trecho seria:
on:
label:
types:
- created
push:
branches:
- main
Ou, de forma mais compacta:
on: [push, label]
Neste caso, o workflow seria acionado por qualquer push (em qualquer branch) e por qualquer criação de etiqueta. Para restringir o push à branch main, a primeira forma é a mais adequada.
A pegadinha desta questão está na sintaxe do YAML e na semântica dos eventos do GitHub Actions. O candidato pode ser induzido a acreditar que o trecho está correto porque vê label com types: created (que está correto) e page_build com types: main (que parece plausível, mas não é). A banca explora a confusão entre page_build e push, e entre types e branches.
NÃO CAIA NESSA!
A banca troca o evento push por page_build e usa types: - main em vez de branches: - main. O candidato que conhece a sintaxe do GitHub Actions percebe o erro imediatamente; o que não conhece pode achar que page_build é um sinônimo de push e que main é um tipo de atividade válido. Lembre-se: push é o evento, branches é o filtro para a branch, e types é o filtro para o tipo de atividade (como created, edited, deleted).
PEGA ESSA DICA!
Para questões de GitHub Actions, memorize a estrutura básica do campo on:
on: [evento1, evento2] — lista simples.
on: {evento: {filtro: [valor]}} — configuração detalhada.
Para push, o filtro é branches (ex.: branches: [main]).
Para label, o filtro é types (ex.: types: [created]).
page_build é um evento separado, relacionado ao GitHub Pages, não ao push.