{"id":10682,"date":"2022-02-07T19:26:08","date_gmt":"2022-02-07T19:26:08","guid":{"rendered":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/07\/how-to-use-github-actions-to-automate-your-repository-builds-cloudsavvy-it\/"},"modified":"2022-02-07T19:26:08","modified_gmt":"2022-02-07T19:26:08","slug":"how-to-use-github-actions-to-automate-your-repository-builds-cloudsavvy-it","status":"publish","type":"post","link":"https:\/\/mailinvest.blog\/index.php\/2022\/02\/07\/how-to-use-github-actions-to-automate-your-repository-builds-cloudsavvy-it\/","title":{"rendered":"How to Use Github Actions to Automate Your Repository Builds \u2013 CloudSavvy IT"},"content":{"rendered":"

<\/a>\n<\/p>\n

\n

\"\"<\/p>\n

If you\u2019re tired of building and releasing your application manually, it might be time to set up a CI\/CD pipeline. Github Actions makes this process easy and free for most projects, and can save you time by automating your app\u2019s building process.<\/p>\n

What Are Actions?<\/h2>\n

Github Actions are tasks that run in the cloud. They can be set up with YAML configuration files, and triggered based off things happening in your account. This is commonly something like \u201cnew commit pushed to master branch,\u201d but Actions can actually be set up for lots of different events<\/a>, including when new issues or made, or even on a schedule as a cron job.<\/p>\n

In this case, we\u2019d like to set up an automated build. This process usually will run whenever changes to the repository are made. You can set this up however you\u2019d like\u2014it\u2019s common practice to run it on the master<\/code>\u00a0or release<\/code>\u00a0branch, but you can also run builds on dev and feature branches.<\/p>\n

Most build processes will also involve testing, and Github Actions can do that too. This can be helpful to catch commits that cause the build to fail. You probably don\u2019t want to deploy failed builds either, so running testing beforehand in all cases can be beneficial.<\/p>\n

With Github Actions, you can also automate the release portion of your deployment. If you have a release<\/code>\u00a0or master<\/code>\u00a0branch that you always update from, you can treat that branch as your deployment source. You servers will download the binaries from the Github Action\u2019s output and update your code. This is made even easier if you\u2019re using a package manager or registry like NPM,\u00a0Maven, or the Docker Hub\u2014updates can be pushed directly to the registry and pulled when needed.<\/p>\n

Setting Up an Automated Build<\/h2>\n

Github Actions use a YAML based configuration system. You\u2019ll need to define two basic things\u2014when the action triggers, and what steps are taken once it does.<\/p>\n

Your exact configuration is going to very wildly depending on what language, framework, and build system you\u2019re using for your application. The general process is fairly similar though, and for this example, we\u2019ll set up a build for a Java based application using the Gradle build tool.<\/p>\n

Head over to your repository and click on \u201cActions.\u201d Github is smart enough to recognize the kind of app your repo contains, and here it recommends a few different actions for building Java.<\/p>\n

\"\"<\/p>\n

Clicking on \u201cJava with Gradle\u201d brings up the Github editor for the YAML file, preconfigured with a Java build. This runs on every push to master, and every pull request to master. You can change this to run on other branches as well, or set up a different action for dev\/feature branches.<\/p>\n\n

\"\"<\/p>\n

You can edit any variables here and click \u201cCommit\u201d on the right when you\u2019re done. Committing will trigger a build if you have it set up to run on push.\u00a0<\/p>\n

You can find the in-progress workflow runs under the Actions tab.<\/p>\n

\"\"<\/p>\n

Troubleshooting Failed Builds<\/h2>\n

Of course, it\u2019s not always that easy\u2014in the real world, build environments can be very fragile, and can fail for a multitude of reasons. The example action Github gave for this repository didn\u2019t make it past startup: it can\u2019t even locate gradlew<\/code>\u00a0to run the build.\u00a0<\/p>\n

\"\"<\/p>\n\n

A strange error considering that should work out of the box, but a quick search of the problem reveals we should probably use the correct\u00a0gradle-build-action<\/code><\/a>\u00a0and manually configure the version and arguments.<\/p>\n

To edit your action configuration, head over to your actions and click the .yml<\/code>\u00a0file under the workflow name to pull up the editor.<\/p>\n

\"\"<\/p>\n

Then, you can patch it up as needed, and commit it again. Committing changes to build.yml<\/code>\u00a0counts as a commit to master<\/code>, so it will trigger the action again.<\/p>\n

\"\"<\/p>\n

This time, it works correctly, though it again failed because of a small mistake\u2014this repository wants Gradle 7.1, not 6.5. You\u2019ll need to fix all these issues for whatever build pipeline you\u2019re using, in order for it to perfectly match the build that you would do manually on your machine.<\/p>\n

\"\"<\/p>\n

Using Your Build Artifacts<\/h2>\n

Once that\u2019s all sorted, we finally get to see the green check mark of success.<\/p>\n

\"\"<\/p>\n\n

Except, it\u2019s not really a useful build\u2014where are the build artifacts? By default, this action just builds the repo, and doesn\u2019t make any output items available.\u00a0<\/p>\n

- name: capture build artifacts
\nuses: actions\/upload-artifact@v2
\nwith:
\nname: Artifacts
\npath: build\/libs\/<\/pre>\n
Running the build again uploads the artifacts properly.<\/p>\n
\"\"<\/p>\n
If you want to have these automatically downloadable, you will want to change the action to run whenever a release tag is created on Github, and then publish to Github packages using your token (which is passed as an environment variable).<\/p>\n
on:
\n  release:
\n    types: [created]
\n
\n...
\n
\n- name: Publish to GitHub Packages
\n      uses: gradle\/gradle-build-action@4137be6a8bf7d7133955359dbd952c0ca73b1021
\n      with:
\n        arguments: publish
\n      env:
\n        USERNAME: ${{ github.actor }}
\n        TOKEN: ${{ secrets.GITHUB_TOKEN }}<\/pre>\n<\/div>\n