CI/CD with GitHub Actions for Flutter projects - Part 2

Recently we were discovering how to use GitHub Actions in our Flutter projects in order to maintain a CI/CD that would allow us to be automatically triggered by running one or more jobs. 

We were also finding out how to keep sensitive data locally on our computers. 

Today we will go a step further and see how to configure our CI/CD so that it can read this data securely without having to expose our beloved and sensitive information. 

Let's get down to business

In GitHub, we will go to the Settings tab of our project.

In the menu on the left, scroll down to the Security section. The section that matters to us is Secrets and variables.

As you can see, we can create secrets and encrypted variables of 3 types. Actions secrets (for GitHub Actions), Codespaces secrets and Dependabot secrets. We will focus on the first one, as they are the ones that will allow us to use them in the GitHub Actions but if we want to perform more complex tasks in Dependabot or use the development environment that's hosted in the cloud. 

Secrets and variables allow you to manage reusable configuration data. Secrets are encrypted and are used for sensitive data. Learn more about encrypted secrets. Variables are shown as plain text and are used for non-sensitive data. Learn more about variables.

Anyone with collaborator access to your repository can use these secrets and variables for actions. They are not passed to workflows that are triggered by a pull request from a fork.

If we click on Actions we will see a window like the following one: 

Now we will start creating each of the secret variables we need by clicking on the New Repository Secret button:

For each secret we have to give it a name with which we will access it in the continuous integration and a value, with the content of the secret. 

Note: A simple way to load all the sensitive data we had stored in the local .env file is to add the entire contents of the .env file as a secret. For example, we will call this secret FLUTTER_ENV_FILE and as we said, the value of the secret will be a copy and paste of the whole content of the .env file from the project we created in the other post.

You should now see your new secret as follows:

We can now modify the job inside the YAML file we created last day to load the .env file into the container where we are running our Workflow.

With '${{ secrets.FLUTTER_ENV_FILE }}' command we will be accessing the secret and with > .env we will create a file named .env and it will load the file with contents of the secret.

Another way instead of adding the entire contents of the file is to add it line by line. This is especially useful when some of the fields depend on previous secrets.  For example:

Conclusions

This opens up a lot of possibilities as we will see in future posts. We can keep our distribution certificates, Service configuration files and any other sensitive data as secrets and this will be mandatory for any secure and well configured Continuous Distribution system. I'll give you as example a part of the Android distribution workflow of Drag PDF.

But as I said, the Continuous Delivery (CD) will be the next thing we'll deal with.

See you in other posts!!