I really recommend that you give GitHub Actions a try in your next Android project. Note that we usually have the Keystore file on our private repos, if you don’t want to have it there or you’re working on a public repo, you can also add it to your secrets and then decode it when running the workflow. You also must add the release Keystore passwords and alias to the GitHub secrets as those are needed on this job and are sensitive data. For that please follow the instructions here. You’ll need to add some configurations into your Android project to have this task available. Lastly, we are publishing the app using the Gradle Play Publisher plugin.
After creating the account you can download the JSON key and add it to the secrets like you’ve done before with the Google services JSON. We also need to create a Google service account to be able to have publish access in the next job.
Like on the testing workflow we need the Google services JSON file so we’re decoding it before running any Gradle task. I’m saying that I want it to run on pushes to the develop branch. Let’s again go step by step to explain everything. # Step 2: Decode Google services configuration fileįIREBASE_CONFIG: $ # Step 1: Choose the branch or branches you want to run this workflow Here is the list of jobs that it performs:ĭecode our Google services config file (if you’re not using Google services or Firebase you can remove this job). The purpose of this workflow is to run some lint checks and to run our tests. You should change all the commands to your correct variant name or remove the staging word from them if you don’t need to use variants. In this example, we’re running the commands for the staging build variant. Please note that we usually create multiple build variants for different environments. The first always runs on pull requests and the last only runs when the code is merged to master or develop. We always have two types of workflows, one for testing and code checking and one for deploying. Here is how we set up GitHub Actions on our Android projects. That way we are sure that our code is always checked, tested and meets our quality standards before being deployed.įor Android specifically, we always used services like TravisCI or CircleCI for this task, but since we are heavy users of GitHub we couldn’t wait to experiment with GitHub Actions and check if it would be a better option for our projects. Like so, continuous integration (CI) and continuous deployment (CD) are some of the first things we focus on before starting to code.
Here at Coletiv, when starting a new project, we always aim to deliver it following the highest standards of quality.
0 kommentar(er)
