Roque Pinel

Using GitHub Actions from private repositories

Sat, 02 Nov 2019 13:03:00 +0000

Updated on 06/18/2020: actions/checkout@v2 can now handle private repositories. See the updated solution.

GitHub Actions are awesome. The ability of build workflows nicely coupled to source code and backed by cloud computing is truly awesome. No wonder the feature will be moving to general availability on November 13.

I was surprised to noticed this week that you cannot use a GitHub action defined in a private repository like you would normally do with a public action.

name: My workflow
on: push
jobs:
  do-something:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: my-organization/awesome-action@master
      - name: Last step
        run: ...

The workflow above will raise a 404 error when trying to use my-organization/awesome-action@master if my-organization/awesome-action is a private repository, even if the workflow’s repository is part of the same organization (my-organization). Okay, let’s try checking out the awesome-action and point the step to its local path in the container.

name: My workflow
on: push
jobs:
  do-something:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/checkout@v1
        with:
          repository: my-organization/awesome-action
          ref: refs/heads/master
          # GitHub's personal access token with access to `my-organization/awesome-action`
          token: $
          path: ./.github/actions/awesome-action
      - uses: ./.github/actions/awesome-action
      - name: Last step
        run: ...

The actions/checkout@v1 is able to checkout my-organization/awesome-action, but the path provided won’t be defined in the next step that tries to use the awesome-action. Someone had reported a similar issue but no one from the GitHub team has reached out. How about a more manual approach?

name: My workflow
on: push
jobs:
  do-something:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: Checkout my-organization/awesome-action
        run: git clone --single-branch --no-tags --depth 1 -b master https://$:$@github.com/my-organization/awesome-action ./.github/actions/awesome-action
      - uses: ./.github/actions/awesome-action
      - name: Last step
        run: ...

Success! The private repository my-organization/awesome-action is correctly cloned to the provided path and the next step is able to use the awesome-action. The git command uses secrets.GIT_USER and secrets.GIT_TOKEN to be able to access the repository. They were definied in the workflow’s repository settings. secrets.GIT_TOKEN is the GitHub’s personal access token with access to my-organization/awesome-action and secrets.GIT_USER its owner.

Updated on 06/18/2020

You can use actions/checkout@v2 to checkout private repositories as first attempted above. The cleaner solution would be:

name: My workflow
on: push
jobs:
  do-something:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Checkout my-organization/awesome-action
        uses: actions/checkout@v2
        with:
          repository: my-organization/awesome-action
          ref: refs/heads/master
          # GitHub's personal access token with access to `my-organization/awesome-action`
          token: $
          persist-credentials: false
          path: ./.github/actions/awesome-action
      - uses: ./.github/actions/awesome-action
      - name: Last step
        run: ...

Including AWS Step Functions definitions in AWS SAM templates

Thu, 06 Jun 2019 22:10:00 +0000

When defining AWS Step Function in AWS Serverless Application Model (SAM), it’s common to have a template like:

# sam.yaml
# ...

MyStepFunctionsStateMachine:
  Type: AWS::StepFunctions::StateMachine
  Properties:
    RoleArn: !GetAtt MyStepFunctionsRole.Arn
    DefinitionString: !Sub |-
      {
        "StartAt": "HelloWorld",
        "Comment": "Say hello world",
        "States": {
          "HelloWorld": {
            "Type": "Task",
            "Resource": "${HelloWorldFunction.Arn}",
            "Comment": "Run the HelloWorld Lambda function",
            "End": true
          }
        }
      }

# ...

The JSON provided to DefinitionString inline can easily get long and make it harder to maintain the CloudFormation template. Thankfully, as described in this GitHub issue, it’s possible to use the macro AWS::Include to include an external template file as the definition of Step Functions.

# sam.yaml
# ...

MyStepFunctionsStateMachine:
  Type: AWS::StepFunctions::StateMachine
  Properties:
    RoleArn: !GetAtt MyStepFunctionsRole.Arn
    Fn::Transform:
      Name: AWS::Include
      Parameters:
        Location:
          Fn::Sub: s3://${BucketName}/state-functions-definition.yaml

# ...

# state-functions-definition.yaml

DefinitionString:
  Fn::Sub: |-
    {
      "StartAt": "HelloWorld",
      "Comment": "Say hello world",
      "States": {
        "HelloWorld": {
          "Type": "Task",
          "Resource": "${HelloWorldFunction.Arn}",
          "Comment": "Run the HelloWorld Lambda function",
          "End": true
        }
      }
    }

Please note that the template file state-functions-definition.yaml would have to be copied to the S3 bucket refered by BucketName in the sam.yaml pior to creating/updating the CloudFormation stack.

Supported functions in Fn::Transform

Thu, 06 Jun 2019 21:25:00 +0000

This is a note-to-self about Fn:Transform in AWS CloudFormation. When combined with the macro AWS::Include, as of today, the included template is limit to these functions:

Fn::Base64
Fn::GetAtt
Fn::GetAZs
Fn::ImportValue
Fn::Join
Fn::Split
Fn::FindInMap
Fn::Select
Ref
Fn::Equals
Fn::If
Fn::Not
Condition
Fn::And
Fn::Or
Fn::Contains
Fn::EachMemberEquals
Fn::EachMemberIn
Fn::ValueOf
Fn::ValueOfAll
Fn::RefAll
Fn::Sub
Fn::Cidr

By the way, isn’t it amazing that only Ref and Condition are available in short form? Where’s the consistency, AWS?

Seeding databases using more complex Rails fixtures

Mon, 25 Apr 2016 23:00:00 +0000

Ruby on Rails applications can be easily tested using fixtures to load the initial data. Each fixture filename would normally match the model name, and any exception to that rule would use the set_fixture_class method to map the fixture and the model.

The set_fixture_class solution works fine for testings, but it fails when seeding databases with rails db:fixtures:load (a.k.a rake db:fixtures:load). The mapping created by the method is only available to tests because it is defined directly into the tests Ruby code. Therefore the db:fixtures:load task cannot use it to load the fixtures.

A solution has recently been introduced to the Rails 5 and will allow the mapping to be done from the fixture file itself. The following case loads the User model from the accounts table:

# schema.rb
create_table "accounts", force: :cascade do |t|
  t.string   "name"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

# user.rb
class User < ActiveRecord::Base
  self.table_name = 'accounts'
end

Using the model_class property from _fixture in the YAML file, the accounts fixtures can now instantiate User records:

# accounts.yml

_fixture:
  model_class: User

admin:
  name: 'Foo'

That allows db:fixtures:load to recognize the model and to seed the records. The setting is also transparent to the model associations. So if there is a scenario where a user can have many roles, it can be described in the roles fixture without any mention to accounts:

# schema.rb
create_table "roles", force: :cascade do |t|
  t.string   "name"
  t.integer  "user_id"
  t.datetime "created_at", null: false
  t.datetime "updated_at", null: false
end

# role.rb
class Role < ApplicationRecord
  belongs_to :user, inverse_of: :roles
end

# user.rb
class User < ActiveRecord::Base
  self.table_name = 'accounts'
  has_many :roles, inverse_of: :user, dependent: :destroy
end

And for the roles fixtures:

# roles.yml
admin_role:
  name: 'admin'
  user: admin

Back to the tests, the set_fixture_class method will overwrite any model_class setting in fixtures for a more refined control.

Gerando plugins NPAPI no Windows

Wed, 16 Mar 2011 01:10:00 +0000

Muitas das extensões para Firefox e Chromium, que são limitadas pelo suporte da API, acabam recorrendo a plugins NPAPI para solucionar seus problemas. Plugins NPAPI são programas capazes de serem acessador via JavaScript, e podem ser escritos em linguagens como C++, que facilita em muito certos trabalhos.

Contudo, a maioria dos plugins possui um núcleo comum, que consiste de sua integração com o navegador. Assim, por que não escrever apenas as funcionalidades que efetivamente caracterizam o plugin? Isso pode ser obtido com o uso de frameworks, como Nixysa e Firebreath.

Apesar do framework Nixysa ser mais simples, a pouca documentação torna o trabalho um pouco mais complicado, principalmente para criação de plugins NPAPI em ambientes Windows, as conhecidas DLLs. Assim, descreverei como gerar o plugin a partir do projeto exemplo Complex.

Primeiramente, precisaremos instalar algumas dependências:

Um cliente do Subversion, recomendo o Win32Svn.
Python 2.7.1.
PyWin32-216 para Python 2.7.
Se seu sistema for o Windows XP, instale o Service Pack 3.
Microsoft Visual C++ 2005 Express Edition.
Microsoft Platform SDK.

Após a instalação das dependências, seguindo as opções padrão, adicione alguns diretório ao PATH do ambiente. Verifique se os caminhos utilizados são compatíveis com seu Windows.

C:\Python27
C:\Program Files\Subversion\bin

Abra o Prompt de Comando, pressione Win+E e digite cmd. Digite os seguintes comandos no terminal:

cd \
mkdir Sources
cd Soruces
git clone https://github.com/google/nixysa.git nixysa-read-only

Descrição dos comandos por linha:

Abre a raiz do seu sistema.
Cria o diretório Sources, onde o projeto será baixado. Você pode alterar o nome do diretório, mas ele não deve conter espaços ou qualquer caracter especial.
Entra no diretório recém criado.
Baixa a última versão do repositório do Nixysa, atualmente a versão 75.

Utilizando o comando dir, é possível verificar que o nixysa-read-only foi criado. Depois abra o Microsoft Visual Solution (complex.sln) do projeto exemplo.

cd nixysa-read-only\examples\complex
start complex.sln

Configure o VC++ para trabalhar com o Microsoft Platform SDK. Entre em Tools -> Options -> Project and Solutions -> VC++ Directories e adicione os seguintes diretórios:

Executable files: C:\Program Files\Microsoft Platform SDK\Bin
Include files: C:\Program Files\Microsoft Platform SDK\Include
Library files: C:\Program Files\Microsoft Platform SDK\Lib

Agore adicione algumas definições para o preprocessador. Entre em Project -> Configuration -> C/C++ -> Preprocessor e adicione _X86_;X86 a Preprocessor Definitions.

Abra o arquivo complex.rc e substitua a linha #include "afxres.h" por #include "windows.h". Agora bastar pressionar F7 para realizar o build do projeto. A DLL npcomplex.dll poderá ser encontrada no diretório nixysa-read-only\examples\complex\DEBUG. O plugin também será automaticamente copiado para o diretório %USERPROFILE%\Application Data\Mozilla\Plugins, em que %USERPROFILE% representa o diretório do usuário.

Para testar o plugin, basta abrir o arquivo nixysa-read-only\examples\complex\test.html no Firefox. Lembrando que para testar em navegadores Chromium, a linha <object type='application/complex' id='plugin' width='0' height='0'> </object> deve ser substituída por <embed type="application/complex" id="plugin" width='0' height='0'/>.

Recomendo também verificar os vídeos do Firebreath, a documentação é bem mais completa que o Nixysa.

Acessando partições Ext4 no Mac OS X

Sat, 05 Mar 2011 20:40:00 +0000

Há algum tempo estive procurando por uma solução eficiente para acessar os dados da partição Ext4 do Ubuntu no Mac OS X (veja Instalando o Ubuntu Minimal no MacBook). O objetivo era encontrar algo semelhante ao projeto fuse-ext2, que além de facilitar a configuração do ambiente, permite montar automaticamente tanto HD internos e externos.

Acabei encontrando o projeto ext4fuse, criado e mantido por Gerard Lledó. O ext4fuse é normalmente disponibilizado como código fonte, diretamente do GitHub, e depende do MacFUSE devidamente compilado para ser compilado. Contudo, não consegui compilar as dependências utilizando a última versão do Xcode do Mac OS X Leopard :-(

$ ./core/macfuse_buildtool.sh -t smalldist
failed to determine Xcode version.

Não tendo como resolver a situação, entrei em contato com o Gerard e obtive o binário do ext4fuse. Com ele consegui habilitar corretamente a leitura de partições Ext4. Para configuração do ambiente, baixe o binário e execute os seguintes comandos no diretório onde ele se encontra:

sudo cp ext4fuse-24810919 /usr/local/bin/ext4fuse
sudo ln -s /usr/local/bin/ext4fuse /sbin/mount_fuse-ext4

Dessa forma, querendo montar, por exemplo, a partição /dev/disk0s2 em /tmp/discoExt4, pode-se utilizar os seguintes comandos:

sudo mkdir /tmp/discoExt4
sudo mount -t fuse-ext4 /dev/disk0s2 /tmp/discoExt4

O mesmo pode ser automatizado criando-se um script com os comandos e executando-o ao iniciar o sistema.

Configurando o Apple Remote Control no Ubuntu

Sat, 05 Mar 2011 19:56:00 +0000

Mais um artigo da série Instalando o Ubuntu Minimal no MacBook. Agora apresentando os passos de configuração do controle remoto infravermelho do MacBook no Ubuntu.

Para o reconhecimento do infravermelho e ativação dos comandos que deverão ser executados para cada tecla do controle, utilizaremos o pacote LIRC (Linux Infrared Remote Control). No Ubuntu, ele pode ser instalado, juntamente com os utilitários, a partir dos comandos como super usuário:

aptitude -y install lirc lirc-x xautomation
mkdir /etc/lirc/lirc

Após a instalação, basta criar o arquivo de configuração para começar a utilizar o controle de remoto. O arquivo de configuração fica localizado em /etc/lirc/lirc/lircrc e contém o mapeamento dos comandos que serão executados para cada ação do controle. Meu arquivo pode ser baixado aqui. A seguir são exibidos dois blocos de configuração desse arquivo.

begin
  prog = irexec
  button = PLAY
  config = xte 'key XF86AudioPlay'
end

begin
  prog = irxevent
  button = PLAY
  config = Key F5 CurrentWindow
  repeat = 0
end

O primeiro bloco é ativado quando o daemon irexec está executando, já o segundo é ativado quando o irxevent está executando. Ambos representam ações que deve ser executadas quando botão PLAY for utilizado. Sendo o primeiro bloco responsável por simular a tecla play do teclado, e o segundo a tecla F5.

No meu caso, eu sempre ativo o irexec para funções multimídias e o irxevent para apresentações. Contudo, como ativar e desativar os daemons não era uma tarefa prática, resolvi criar o um GNOME Applet específico para trabalhar com o LIRC, o ir-switcher. Para instalá-lo, basta executar os comandos como super usuário:

wget -O ir_switcher.deb https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ir-switcher/ir_switcher_0.1_all.deb
dpkg -i ir_switcher.deb
rm ir_switcher.deb

Depois é preciso adicioná-lo em um painel do seu ambiente, conforme a imagem.

Clicando com o botão direito do mouse sobre o ícone é possível escolher qual daemon executar: irexec, irxevent ou os dois. Para iniciar a execução do daemon selecionado, clique com o botão esquerdo do mouse sobre o ícone e mesmo mudará, indicando a ativação.

Um artigo mais completo sobre as diferentes configurações do LIRC pode ser achado no Viva o Linux. Qualquer dúvida sobre a utilização do ir-switcher, não deixem de entrar em contato.

Configurando a webcam iSight no Ubuntu

Sat, 05 Mar 2011 19:03:00 +0000

Continuando o artigo Instalando o Ubuntu Minimal no MacBook, descreverei como configurar a webcam iSight do MacBook no Ubuntu.

O driver utilizado pelo Kernel para se conectar a câmera é proprietário, mas pode ser obtido a partir do sistema MacOS instalado no próprio MacBook. Considerando, por exemplo, que o MacOS está instalado em /dev/sda1, podemos utilizar os seguintes comandos como super usuário:

cd
mkdir /mnt/macosx
mount /dev/sda1 /mnt/macosx
cp /mnt/macosx/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport .
umount /mnt/macosx

Dessa forma, teremos uma cópia do arquivo AppleUSBVideoSupport na home do super usuário. Agora precisaremos extrair o firmware do driver e instalá-lo.

add-apt-repository ppa:mactel-support/ppa
aptitude update
aptitude upgrade
aptitude -y install isight-firmware-tools
cp AppleUSBVideoSupport /lib/firmware/
ift-extract --apple-driver /lib/firmware/AppleUSBVideoSupport
rm /lib/firmware/AppleUSBVideoSupport

Tendo executado esses comandos o firmware da webcam já deve estar disponível para ser carregar na próxima vez em que o sistema iniciar. Para testar a captura da imagem, uma boa dica é o programa Cheese. Ele pode ser instalado diretamente pelo próprio terminal.

aptitude -y install cheese

Lembrando que ao atualizar a versão atual do Kernel, o firmware deve ser novamente instalado.

Instalando o Ubuntu Minimal no MacBook

Fri, 04 Mar 2011 16:51:00 +0000

As máquinas da Apple não são apenas conhecidas pelo design clean e arrojado, elas também possuem ótima arquitetura computacional. Seus portáteis, como os MacBooks, são reconhecidos por serem mais leves que a maioria da categoria, o que justifica o grande sucesso.

Mesmo aqueles que não são usuários exclusivos do sistema MacOS acabam optando por esses equipamentos. Mas como deixar seu sistema mais próximo do desempenho do MacOs em MacBooks? Como sugestão, volto ao artigo Tirando o melhor do Ubuntu, que aborda as características do sistema Ubuntu Minimal.

Algum tempo atrás nem todas as funcionalidades dos MacBooks podiam ser exploradas, como utilizar multi-touch no trackpad e controlar o brilho da tela. Mas hoje, além dessas funcionalides, já temos o aperfeiçoamento da duração bateria em sistemas Linux, devido a novas características do Kernel.

O passo inicial para a instalação de um segundo sistema operacional em qualquer máquina é o particionamento, ou reparticionamento. No MacOS, isso pode ser feito através do programa BootCamp, utilizado na instalação do Windows. O BootCamp pode ser encontrado na pasta Utilities, e como queremos instalar o Ubuntu, iremos utilizá-lo somente até o reparticionamento. Recomendo deixar pelo menos 5GB para o Ubuntu, conforme a imagem.

Após ajeitar o espaço em disco, precisamos permitir o boot do novo sistema. Como a tabela de partições do MacBook não exatamente como a de PCs, não podemos utilizar diretamente o GRUB ou o LILO, assim instalaremos o rEFit. Basta baixar o pacote DMG da última versão, montá-lo e abrir o rEFit.mpkg.

Para que a instalação tenha efeito, desligue o MacBook, não reinicie. Ao ligá-lo novamente, deverá aparecer uma tela semelhante a seguinte.

Com isso, já podemos continuar a instalação do Ubuntu. Baixe e grave a imagem do Ubuntu Minimal em um CD. É importante lembrar que durante todo o processo de instalação seu computador deve estar conectado a internet, pois os pacotes do sistema serão baixados sob demanda.

Para realizar o boot do CD, pressione e segure a tecla C ao ligar o MacBook. Para que o boot ocorra corretamente, sempre desligue a máquina antes de tentar entrar pelo CD, não apenas reinicie. Dentre as opções, escolha Install.

Durante o processo de instalação, certifique-se de escolhar o teclado correto. Utilizei o USA Macintosh durante a instação, mas atualmente utilizo o USA International (with dead keys) devido a acentuação.

Outro ponto importante é a escolha de onde instalar o GRUB, o boot loader. Ele deve ser instalado na mesma partição do Ubuntu. Se, por exemplo, o Ubuntu foi instalado em /dev/sda2, então o GRUB também deve ser instalado em /dev/sda2.

Seguindo esses passos, Ubuntu deve ser reconhecido pelo rEFit e essa tela aparecerá ao ligar o MacBook.

Ao iniciar o Ubuntu, ele consistirá apenas do terminal, sem gerenciador de janelas. Nesse ponto, volto a sugerir o script do grupo Minimal Desktop for Ubuntu. As configurações especiais para o MacBook serão abordadas em posts separados, devido ao aumento da complexidade. Contudo, deixo meu script disponível, visto que ele já possui algumas indicações interessantes.

Tirando o melhor do Ubuntu

Sun, 27 Feb 2011 23:39:00 +0000

Há alguns anos sou usuário dedicado de sistemas Linux. Começando pelo famoso Slackware, passando pelo mal compreendido Linux from Scratch (LFS), o adorável Gentoo, até chegar no prático Ubuntu.

Todas essas distribuições me renderam bom conhecimento e algumas boas práticas. Sempre afirmo que se você deseja conhecer melhor como ambientes Linux funcionam, uma sugestão seria se dedicar por um tempo ao LFS. Inclusive temos uma boa comunidade aqui no Brasil, o LFS-BR.

Mas recentemente, por sugestão de um amigo, entrei em contato com a versão mínima do Ubuntu. O Ubuntu Minimal, como é conhecido pela comunidade, representa a base comum do sistema, sem os adicionais, como o gerenciador de janelas. Como vantagens dessa versão, temos a redução dos serviços instalados, assim como a remoção de componentes que acabariam nunca sendo usados pelo usuário.

Exatamente por não conter o ambiente gráfico de janelas, o usuário precisa fazer a instalação dos primeiros programas por linha de comando, o que acaba sendo um pouco assustador para alguns. Pensando nisso, e para deixar tudo mais prático, uma parte da comunidade tem se dedicado ao grupo Minimal Desktop for Ubuntu. O grupo consiste de pessoas que documentaram fielmente os passos de instalação e ainda criaram um script interativo para a instalação dos aplicativos básicos, entre eles o ambiente gráfico de preferência.

Fico feliz em ver que o Ubuntu tem satisfeito tanto os usuários iniciantes como os avançados. E nada melhor do que o comentário de Linus Torvalds em entrevista a OMG! Ubuntu!:

I think that Ubuntu has done a really, really good job making Linux available to a wider and different audience.