Official DNSControl action

[eliheady]

In the last dev meeting, the topic of producing an official GitHub Action for DNSControl was raised. There are many actions in the marketplace and presumably many more private actions to install dnscontrol in workflows.

I promised to start this discussion to determine whether there was a standout community action already out there on which to base a new 'official' action.

Is there interest here in establishing action interface features (inputs and outputs) beyond the simplest inputs: dnscontrol command arguments, config file and creds file, and output from the executed command as action output?

I would like to see additional features implemented that are not interface related but meta features related to maintenance of the dnscontrol-action like triggered builds based on new releases of the main project, verifying build attestation of the docker image once that is in place in DNSControl, applying linters to the Containerfile, entrypoint, and other lintable components.

What else should be considered essential to include?

[tlimoncelli]

Hi Eli! Thanks for stepping up to work on this!

Some features I'd like to see:

Posting the output as a comment should be off be default, but easy to enable. You generally want preview to post the output as a comment, but not push. There are many actions that post comments. I think they all do that trick where each re-run of preview updates the same comment rather than making the "conversion" longer. This prevents the "conversation" about the PR from getting cluttered.

Ours looks something like:

    -
      name: Attach Results as PR comment
      uses: thollander/actions-comment-pull-request@v2
      with:
        comment_tag: dnscontrol_preview_push_external
        message: |
          <details open><summary>DNSControl PREVIEW Results</summary>

          ### DNS Control PREVIEW Results

          ```
          ${{ steps.dnscontrol_preview_external.outputs.dnscontrol_results }}
          ```
          </details>

The ability to send flags to the preview/push command separately. We run preview with "preview --reportmax=0" and push with "push --notify --reportmax=10". The action should be generic, requiring the user to specify the command and all args. That way it can be used whether you want to push, preview, or even check.

Disable color. Force color off:

      env:
        NO_COLOR: 'true'

Don't do too much. Don't try to do any authentication inside the action. Leave that to the workflow.

Example workflow should be aware that a "cancelled" PR still runs the action. We learned this the hard way. The action that is called when the PR is closed must first determine why it was closed and act different if it was closed due to being cancelled.

      if: ${{ !cancelled() }}

Before we added this little if, we found that cancelled PRs were still being pushed. Hilarity ensured.

[eliheady]

Thanks Tom!

Hilarity ensured.

ha! I'm sure

Have you ever wanted the output of the command to be written to a file in the runner workspace? I am experimenting with it and could see it being useful as a file attachment on a release if one uses releases as part of a push workflow.

[tlimoncelli]

Having the output available as a file is useful. In fact, our internal GHA only generates the file and leaves it up to the caller to attach it as a comment. I would prefer the GHA have a flag to post the comment (or the absence of a comment_id implies no comment will be posted).

[tlimoncelli]

Here's a test case: If dnsconfig.js has a syntax error and bombs before preview can begin, the error message should appear somewhere. (I'm only suggesting this because we had this bug.)

[eliheady]

I like having the action append output to GITHUB_STEP_SUMMAY so that the job summary page has something useful and I don't have to look through the step outputs, but also posting errors to the PR would be useful.

[tlimoncelli]

Sounds good!

[eliheady]

I have been experimenting with the existing published actions, and writing new composite actions and reusable workflows to implement some of the features we've talked about and one brick wall keeps appearing: secrets to populate creds.json ...

I use a creds.json with environment variable references, and in my own repo I have those values stored in action secrets. When I run dnscontrol in a step, I explicitly list out all of the required secrets in an env block, like this

      - name: DNSControl
        id: dnscontrol
        env:
          NO_COLOR: 'true'
          DNSCONTROL_ROUTE53CORE_KEY_ID: ${{ secrets.DNSCONTROL_ROUTE53CORE_KEY_ID }}
          DNSCONTROL_ROUTE53CORE_KEY: ${{ secrets.DNSCONTROL_ROUTE53CORE_KEY }}
          DNSCONTROL_ROUTE53_KEY_ID: ${{ secrets.DNSCONTROL_ROUTE53_KEY_ID }}
          DNSCONTROL_ROUTE53_KEY: ${{ secrets.DNSCONTROL_ROUTE53_KEY }}
          DNSCONTROL_INWX_1_USER: ${{ secrets.DNSCONTROL_INWX_1_USER }}
          DNSCONTROL_INWX_1_PASSWORD: ${{ secrets.DNSCONTROL_INWX_1_PASSWORD }}
          DNSCONTROL_INWX_2_USER: ${{ secrets.DNSCONTROL_INWX_2_USER }}
          DNSCONTROL_INWX_2_PASSWORD: ${{ secrets.DNSCONTROL_INWX_2_PASSWORD }}
        run: |
          dnscontrol ...

I know about secrets: inherit that one can use to have a called reusable workflow see all the repo secrets, but I haven't figured out how to get the environment to have fully resolved secret values when dnscontrol runs without using that verbose method above. That obviously will not work for this task we're discussing because the variable names will be unknown (and populating all of them seems just wrong even if they were standardized).

So, am I doing it wrong or just in need of a good cluebat whack? (asking the universe here, not just you Tom)

[eliheady]

But I don't know if I can live with it forever if there is a need to support multiple OS and arch combinations ... so I'm mulling that over.

[eliheady]

Tom, you referenced a PowerShell step in that example - are you all using windows runners? If so, I'm now thinking about what in the action needs to be added or changed to be multi OS compatible.

[tlimoncelli]

But I don't know if I can live with it forever if there is a need to support multiple OS and arch combinations ... so I'm mulling that over.

Exactly. It's a trade-off between letting someone else handle future changes at Github and/or OS changes vs. the challenges of having additional external dependencies. I don't have an opinion here. That said, "if it works, don't fix it" might be the appropriate strategy.

[tlimoncelli]

Tom, you referenced a PowerShell step in that example - are you all using windows runners? If so, I'm now thinking about what in the action needs to be added or changed to be multi OS compatible.

I don't recommend using PowerShell in your Action... the 2 lines should be easy to translate to Bash even if you don't know PS.

GHA images come with Linux PowerShell pre-installed so you can access it by simply specifying it as a shell. You can mix bash and powershell steps. Our internal GHA originally ran exclusively on Windows because it had to talk to ActiveDirectory DNS. That requirement was removed in June/July of this year (thus DNSControl deleted the MSDNS provider since I also lost the ability to debug the provider).

[eliheady]

Here is the usage example I added to the readme that uses the pre-populated creds.json approach to sharing credentials with the action. I also added a warning note about using environment variables in the GitHub runner context. https://github.com/eliheady/dnscontrol-action-experiment

    steps:
      -
        name: Checkout repo
        uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4.3.0
      -
        # add all secrets needed for creds.json variable interpolation
        name: Prepare creds_file
        run: |
          cat >creds-populated.json<<EOF
          {
            "route53": {
              "TYPE": "ROUTE53",
              "KeyId": "${{ secrets.DNSCONTROL_ROUTE53_KEY_ID }}",
              "SecretKey": "${{ secrets.DNSCONTROL_ROUTE53_KEY }}"
            }
          }
          EOF
      -
        # call the action with options to run `dnscontrol check` before `dnscontrol preview`,
        # post to the PR, and post to the job summary
        name: call dnscontrol action
        uses: eliheady/dnscontrol-action-experiment@25d93bea2db9cae2c3ff71098cc82015de781938 # v0.0.3
        with:
          cmdargs: preview
          post_pr_comment: true
          post_summary: true
          check: true
          creds_file: creds-populated.json

[jauderho]

Feel free to cherrypick anything from https://github.com/jauderho/dnscontrol-action

Some differences:

• Points to Docker image that I maintain at ghcr.io/jauderho/dnscontrol (60k downloads) [1]which means Dependabot will pick up the right version assuming that dependabot.yml is configured accordingly
• All actions are hashed per best practices
• Took a bit to figure out how to publish to marketplace (as I use this action myself) but it is published

I look forward to a consolidated official action so that I can stop using mine.

[1] https://github.com/jauderho/dockerfiles/blob/main/dnscontrol/Dockerfile