• GitHub Action build not running on main/master

    Maybe I could call this ‘The case of the Grumpy GitHub Action’?

    I recently added the Auto-merge on a pull request workflow to my https://github.com/flcdrg/dependabot-lockfiles repository.

    The idea being that when Dependabot creates a pull request to update a component, if you’ve set the Allow auto-merge option in the repository settings, then the pull request can be merged automatically assuming all requirements are met.

    But I’d noticed after making that change, while builds were running correctly for pull requests, the merge commit didn’t have a corresponding build!

    Main branch commits and build status

    My first thought was had I made a mistake in one of the workflows? But they were working for pull requests. If there was a typo it should have shown up there.

    I then took a closer look at the builds that were working. Looking at the screenshot above, I’m expecting to see a green tick next to each merge commit (the commits labelled ‘Merged pull request’).

    There’s ones for the two pull requests that I created myself (my GitHub username is ‘flcdrg’), but none for the most recent commit. And interestingly that merge commit says it’s committed by ‘github-actions’. Hmm.. I wonder if that’s significant?

    It reminded me of something I’d read previously.

    When you use the repository’s GITHUB_TOKEN to perform tasks on behalf of the GitHub Actions app, events triggered by the GITHUB_TOKEN will not create a new workflow run.

    I began to form a hypothesis. The auto-merge is set by that workflow looks like this:

          - name: Enable auto-merge for Dependabot PRs
            run: gh pr merge --auto --merge "$PR_URL"
              PR_URL: ${{github.event.pull_request.html_url}}
              GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

    It’s using the GitHub CLI to configure the pull request to enable auto-merge. What I did notice is that it’s passing through GITHUB_TOKEN as an environment variable. On reflection, that kind of makes sense as if you recall the merge commit was ‘committed’ by ‘github-actions’. I guess that’s the username that is associated with GITHUB_TOKEN.

    I wondered whether changing the token might help.

    I have a personal access token that I’d previously created with repository access. I added it as a secret named PAT_REPO_FULL to this repository and updated the workflow to use ${{secrets.PAT_REPO_FULL}}.

    Merge commit build success

    The next Dependabot pull request then gets merged and this time it shows the committer as me (as the token was for my account), and success, the build now runs correctly!

  • UniFi Controller on a Synology

    I’ve been using Ubiquiti’s UniFi wireless access points for a few years around home. Until now I’ve only used the UniFi Controller application on an as-need basis (when setting the configuration or installing updates). But having the Synology DS1621xs on hand gives me an opportunity to try out its Docker support and in particular being able to run UniFi Controller continuously in a Docker container on the Synology.

    UniFi Controller screenshot

    I say ‘UniFi Controller’ but I gather that as of version 6.2 they’ve renamed it to ‘UniFi Network Application’. Same software, just an updated name.

    Installing Docker on the Synology

    1. Open the Package Center
    2. Select All Packages and scroll down to the Third-party section
    3. In the ‘Docker’ package click Install

      UniFi Controller screenshot

    4. When installation has completed, the button changes to Open. Click on it to open the Docker UI.
    5. The first time you open Docker a welcome screen message is displayed. Select Don’t show this again and close the message.
    6. Docker is now running on your Synology

    UniFi Controller screenshot

    Installing UniFi Controller

    1. Select the Registry page.

      UniFi Controller screenshot

    2. In the search bar enter unifi and click Search.
    3. Double-click on the jacobalberty/unifi image.

      UniFi Controller screenshot

    4. You now need to select a tag. Review the options to understand what the different tag values mean. (Choose latest to go with the latest stable version).
    5. The image is now being downloaded.
    6. Go to the Image page.
    7. When the download has completed, the Launch button will be enabled. Click on Launch.
    8. If desired, you can customise the Container Name.

      UniFi Controller screenshot

    9. Select Enable resource limitation.
    10. Click on Advanced Settings.
    11. Select Enable auto-restart.

      UniFi Controller screenshot

    12. Select Volume tab and click Add Folder.
    13. Select the docker folder and then click on Create Folder.
    14. Enter unifi and click OK.
    15. Click Select.
    16. In the Mount path column, enter /unifi. (See Volumes for volumes used by this image).

      UniFi Controller screenshot

    17. Select Network tab and select use the same network as Docker Host.

      UniFi Controller screenshot

    18. It is recommended to not run this image as root. Go to the Environment tab.
    19. Change the value of RUNAS_UID0 to false.
    20. As we will be binding to a port > 1024, we can also set the value of BIND_PRIV to false.

      UniFi Controller screenshot

    21. Click Apply.
    22. Click Next.
    23. Review the Summary details, then if they look correct click Apply.

      UniFi Controller screenshot

    24. Select the Container page.
    25. You can see the UniFi image is now running in a container.

      UniFi Controller screenshot

    If you have the Synology Firewall enabled, you will need to allow access to the application, the port needs to be opened in the Synology Firewall. In my case because I hadn’t exposed the Synology directly to the Internet, the firewall was disabled. I figured it was probably a good idea to enable the firewall.

    From the Ports documentation there are a number of TCP and UDP ports to select.

    1. Go to the Synology main menu and select Control Panel.
    2. Select Advanced Mode and click on Security.
    3. In the Firewall tab, select the custom profile and click Edit Rules.

      UniFi Controller screenshot

    4. Click Create and under Ports select Custom and then click on Custom.
    5. Ensure Protocol is set to TCP.
    6. In the Ports field enter 8080,8443,8843,8880,6789.

      UniFi Controller screenshot

    7. Click OK, and OK
    8. Click Create and under Ports select Custom and then click on Custom.
    9. In Protocol select UDP.
    10. In the Ports field enter 3478.

      UniFi Controller screenshot

    11. Click OK, and OK
    12. Click OK to save the firewall profile changes.
    13. If it is highlighted, click Apply to save firewall changes.

    Accessing UniFi Controller

    1. Navigate to https://your-synology-box:8443/ (replacing your-synology-box with the DNS name of your Synology).
    2. As the UniFi Controller comes with a self-signed TLS certificate you’ll need to tell your browser to trust the certificate.
    3. After this you should see the UniFi start-up wizard. If this is the first time you’ve used the software, proceed through the wizard following the steps. Alternatively (like me) if you’re migrating from another installation you can click the or restore setup from backup to upload a back from the old system.

    UniFi Controller screenshot

    And with that you should be good to go!

    Final thoughts

    The ability to run Docker containers on a Synology is a great advantage. The UI is easy to use but flexible enough to allow you to run useful Docker images. Do check out my review of the DS1621xs, and check it out on amazon.com or amazon.com.au


  • Passed AZ-204

    I just passed the Microsoft Exam AZ-204: Developing Solutions for Microsoft Azure, which qualifies me for the Microsoft Certified: Azure Developer Associate certification.

    Microsoft Certified: Azure Developer Associate badge

    View my verified achievement from Microsoft

    If you take a look at the skills measured for this exam, it really does cut across a lot of Azure technologies. I hadn’t had deep exposure to all of those even though I’ve been using Azure a lot lately. So to maximise my chances in the exam I also spent time complementing my hands-on experience with some learning and training content:

    1. Completing all the learning paths listed under Microsoft Learn’s AZ-204 Two ways to prepare heading.
    2. I also reviewed all the content in Pluralsight’s Developing Solutions for Microsoft Azure (AZ-204) certification path. Use this link https://referral.pluralsight.com/mQlUV3B to get 50% off your first month or 15% off an annual subscription!

    Like my previous exam in January I took this one at home. One slight hiccup was that despite Pearson VUE’s website clearly saying an external monitor, keyboard and webcam are acceptable as long as your laptop lid is closed (mentioned under ‘Make sure you have the right equipment, Required if using an external monitor with a laptop’), the proctor insisted that was not allowed. I wasn’t going to argue but it was a bit confusing.

    I’m thinking the next exam on my list might be AZ-400: Designing and Implementing Microsoft DevOps Solutions, as when that is combined with today’s effort I’ll be eligible for the Microsoft Certified: DevOps Engineer Expert certification.