Vamos falar um pouquinho mais agora sobre o GitHub Actions. Bom, passando pelos principais componentes e funcionalidades que o Actions oferece, a gente vai estar falando aí de workflows, que são arquivos de YAML, onde a gente faz o mapeamento de quais são os jobs que vão ser executados. A gente tem os eventos, que são os triggers desses workflows, e a gente tem os jobs, que são os mapeamentos para os steps a serem executados. Então, aqui a gente já tem uma estrutura básica de como vai funcionar o GitHub Actions. A gente vai ter um workflow, que vai ser um arquivo de ema, onde a gente vai declarar ali um trigger. Então, basicamente, se a gente vai fazer inter workflow, que vai ser um arquivo de ema, onde a gente vai declarar um trigger. Então, basicamente, se a gente vai fazer interação de forma manual, se a gente vai disparar esse workflow conforme a gente executar um pull request, uma interação no pull request, como o fechamento dele, a aprovação de um code review, se a gente vai disparar direto no push. E o que a gente vai disparar? A gente vai disparar um conjunto de jobs, que são um mapeamento de vários steps, e cada um dos steps a gente coloca exatamente o que a gente vai executar. Então, se a gente vai fazer um build de uma imagem e a gente vai executar testes unitários, a gente está falando basicamente de um workflow com um trigger que pode ser, por exemplo, ao a gente realizar um push, esse workflow vai ter um job de build e lá dentro a gente vai ter dois steps, um que vai fazer o build da imagem, vai rodar um docker build, por exemplo, e um outro que vai rodar ali o comandinho para teste unitário, que aí vai depender de cada uma das linguagens. A gente também tem actions, que são aplicações customizadas para reuso de atividades frequentes, então vamos pensar aqui o seguinte, né? Sempre que a gente tiver que fazer qualquer tipo de interação com o Cloud Provider, utilizando, sei lá, a AWS como exemplo, a gente precisa assumir uma role para a gente conseguir fazer as interações ali, por exemplo, com um registry, né? Ou com algum serviço de compute. Então, para a gente conseguir fazer esse assume role, a gente tem uma action específica para a gente conseguir bater lá na API da AWS, buscar ali os tokens e conseguir seguir com as atividades que a gente mapear ali dentro do nosso workflow. A gente tem os runners, os runners são basicamente os servidores onde a gente vai executar esses workflows. A gente também tem alguns reusables. Imagina que o reusable é um workflow com uma sequência de atividades, mas na mesma linha da action é um conjunto de atividades que a gente quer reaproveitar, então é quase como se fosse um módulo, uma lib, alguma coisa nesse sentido. Bom, dentro desses reusables, dentro desses workflows, a gente também vai ter alguns valores de inputs, que são valores de entrada para um workflow, para uma action, para um reusable. A gente vai ter alguns outputs, que são utilizados para a gente conseguir compartilhar valores de saída entre jobs. Aqui já tem uma característica importante, a gente não consegue, vamos supor, eu executei uma atividade num job, mapeei uma sequência de steps, executei alguma atividade e eu quero que o retorno de alguma dessas atividades seja utilizada num outro job. Eu não consigo fazer isso através de environment ou através de inputs, eu preciso utilizar outputs nesse caso. A gente também tem algumas vars, que são variáveis, configuradas a nível de org, repositório ou environment. E a gente também tem algumas secrets, que são valores sensíveis, mesma forma, configurado a nível de Org, Repository ou Environment. a gente precisa ter as credenciais desse Sonar Cube para a gente conseguir fazer a autenticação e autorização dentro da plataforma. Então, para que esses valores não fiquem disponíveis em clear text dentro do nosso código, a gente consegue também cadastrar essas secrets e aí a gente simplesmente referencia o nome da secret para a gente conseguir resgatar o valor. Bom, entrando um pouquinho mais no detalhe para vocês conseguirem já ter visibilidade de como funciona o Workflow, olhando a documentação, descrevendo basicamente alguns componentes que eu comentei com vocês, Workflow, os eventos, os triggers, os jobs, mapeamento de steps, uma action para a gente conseguir aqui ter custom applications, os runners, que são os servidores onde a gente executa, e a gente chega aqui num exemplo de Workflow, tá bom? Então aqui a gente tem o nome do workflow, a gente também está colocando uma mensagem, isso daqui é opcional, mas o interessante aqui é que a gente está utilizando um contexto do GitHub, onde a gente captura quem que é o autor dessa interação. Isso aqui é interessante porque a gente consegue referenciar, por exemplo, qual que é o nome do repositório, qual que é o ID do commit que a gente está utilizando, ou até o ID do PR, existem diversos valores que a gente consegue buscar dos contextos do GitHub. Esse cara aqui é o evento, ou o trigger que a gente está utilizando. Então esse workflow vai ser disparado sempre que houver qualquer tipo de push dentro do nosso repositório. A gente também consegue deixar isso aqui um pouco mais rico. Então falar assim, tem que ser um push em uma branch com um pattern name específico. Então dá para fazer esse tipo de coisa também. E a gente começa o mapeamento dos nossos jobs a gente tem aqui nesse caso um job que se chama checkbatsversion ele vai ser executado em um runner ubuntu latest tá então aqui basicamente são labels que a gente referencia sempre que a gente coloca nesse formato a gente tá falando de utilizar um runner público mas a gente também consegue utilizar runners privados né by the way se a gente tiver falando de uma grande corporação é a forma que a gente vai acabar utilizando com runners privados e a gente tem um mapeamento de quais são os steps que a gente vai executar então aqui a gente tem quatro steps. O primeiro, a gente está fazendo um checkout. Então, a gente está entrando dentro desse repositório corrente, tá bom? A gente está fazendo a instalação do Node na versão 20. Isso daqui, a gente está falando de um input, tá? Então, esse cara aqui é uma action que tem esse nome e dentro dessa action existem alguns inputs, um deles é esse node version que a gente está fazendo overwrite. Provavelmente tem algum valor default por baixo, mas a gente está fazendo overwrite. E a gente também está executando outros dois steps, que são basicamente comandos shell. Então, um npm install e um bats-v. Tão simples quanto isso.