DEV Community: Matt Gaiser

Free Code Coverage for Pull Requests on GitHub.

Matt Gaiser — Sat, 28 Aug 2021 19:17:47 +0000

Say that you want some of the benefits of CodeCov but your company is too cheap to pay for it or you just don't want to have to go through the procurement process. What do you do?

Step 1: Generate a code coverage report in a text format.

I did this for an Angular project, it was just a matter of changing the test coverage reporters in karma.conf.js to include:

      reporters: [
        { type: 'text-summary',
          dir : '../../coverage',
          file : 'coverage.txt'
        },

This gives me a text file that I can read to get the lines of code coverage. Because code coverage reporting is highly framework and language specific, I am not going to go into detail here about it. Already having the code coverage numbers is a prerequisite for the rest of the tasks.

Step 2: Figure out the grep or awk bash command to read the text file.

My code coverage tool generates this as its text output. This image is from the console, but what it writes to the file is the same.

It lives in the coverage directory in a file called coverage.txt. I want the percent of lines covered by tests, so I use this:

awk '/^Lines/ { print $3 }' < coverage/coverage.txt

Step 3: Have your Github Action generate the coverage report.

I assume that you have already set up automated testing on Github Actions for each PR (but if not, the full code is at the bottom of the page), so all you must do is set up another Github Action that runs the coverage portion and generates the report. You can likely take the existing GitHub Action and just replace its run with these lines.

 - name: Run tests
   run: npm run test:coverage

Step 4: Add mshick/add-pr-comment@v1 to your GitHub Action to add a comment.

Add PR Comment is a GitHub Action that adds a comment to a PR (the name is pretty straightforward). It is what will post the coverage info to the PR. Each time a new push is made, it will make a new comment if the coverage has changed (it will not comment if the coverage has not changed).

- uses: mshick/add-pr-comment@v1
        with:
          message: | <Message goes here without arrows>
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens
          allow-repeats: false # This is the default

Step 5: Use your bash command to get the coverage value and insert it into the comment.

Run the bash command and assign it to a variable. Add the variable to the string and have it printed out.

      - name: Get coverage output
        id: get_coverage
        run: echo "::set-output name=coverage::$(awk '/^Lines/ { print $3 }' < coverage/coverage.txt)"

      - uses: mshick/add-pr-comment@v1
        with:
          message: |
            Lines Covered: ${{steps.get_coverage.outputs.coverage}}
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens
          allow-repeats: false # This is the default

That lets you get this:

Full Example GitHub Action

name: Report Code Coverage

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2

      - name: Use Node.js 12.x
        uses: actions/setup-node@v1
        with:
          node-version: 12.x

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm run test:coverage

      - name: Get coverage output
        id: get_coverage
        run: echo "::set-output name=coverage::$(awk '/^Lines/ { print $3 }' < coverage/coverage.txt)"

      - uses: mshick/add-pr-comment@v1
        with:
          message: |
            Lines Covered: ${{steps.get_coverage.outputs.coverage}}
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          repo-token-user-login: 'github-actions[bot]' # The user.login for temporary GitHub tokens
          allow-repeats: false # This is the default

The Chrome Extension Deployment Checklist

Matt Gaiser — Sat, 01 May 2021 07:59:48 +0000

I always find it frustrating when the documents do not specify exactly what is required for deployment of something to an app store, something which has delayed my current team a few times.

Here is what the Chrome Web Store requires for deployment of an extension:

Title from package*: This is the title that you set in the manifest.json as the value for name.

Summary from package: This is the sentence that you set in the manifest.jsonunder description.

Description*: An up to 16,000 character block of text that focuses on explaining what your extension does and why users should install it.

Category: This is a dropdown of several categories from which you must choose one.

Language: This is a dropdown of many languages from which you must choose one. There is also a localization process for supporting multiple languages.

Store Icon*: This is a 128 pixel by 128 pixel PNG (mandatory file format) image that should work well on both light and dark backgrounds. A 16 pixel margin should be included on all sides of the icon, so the actual icon size should be 96 pixels by 96 pixels.

Global Promo Video: This is intended to by a YouTube video link to whatever promotional video you have made for the extension.

Screenshots*: Screenshots must be 1280 pixels by 800 pixels or 640 pixels by 400 pixels. They must either be JPEG files or 24-bit PNG files with no alpha. At least one is required, but a maximum of 5 are allowed.

Small Promo Tile: This is a 440 pixel by 280 pixel image that must be either a JPEG or a 24-bit PNG file with no alpha.

Large Promo Tile: This is a 920 pixel by 680 pixel image that must be either a JPEG or a 24-bit PNG file with no alpha.

Marquee Promo Tile: This is a 1400 pixel by 560 pixel image that must be either a JPEG or a 24-bit PNG file with no alpha.

Official URL: This is a website URL that needs to be added through the Google Search Console. Unfortunately, a URL cannot simply be pasted in.

Homepage URL: This is another website URL. It can just be pasted in, unlike the Official URL.

Support URL: This is intended to be a website URL.

Single Purpose*: This is the single purpose of the extension that is narrow in scope and easy to understand. It must be less than 1000 characters.

Permission Justifications*: These are 1000 character explanations for why your extension requires certain functionality that can be used to harm extension users. Explain why that permission is specifically required for the purpose of your extension.

Remote Code: This is meant to justify why you are using code which is imported from a server through a <script> tag or modules pointing to external files.

Data Usage: These are a series of checkboxes that ask you about the data that you are collecting, if any. No explanations required, just binary answers.

Payments: Whether your extension requires or can be enhanced by purchasing items, features, or subscriptions.

Visibility: You can set it to public, where it is placed in the Web Store. It can be set to unlisted, where only those with a link see it. It can also be set to private so that

Distribution: A checklist of countries where you might want to distribute the extension.

Happy building!

How to debug an Office.js Manifest File

Matt Gaiser — Tue, 22 Dec 2020 08:47:11 +0000

For the past couple of weeks, I have been developing Microsoft Word Add-in's using the Office.js framework, which lets you create web applications that can interact directly with any Microsoft Office application.

One of the tasks that has taken me the most time so far has been understanding and debugging the manifest.xml file, which is the file where UI components like labels and menus that integrate into the context menu (that box you get when you right-click) or the ribbon (the row of buttons at the top) are defined.

Debugging a manifest.xml file can mean two things. We will cover them both here.

1. Determining if it is valid XML for an Office Add-in

Microsoft provides a tool to check whether your manifest.xml is valid. You can read about it in more detail here, but the basics are below.

If you used the Yeoman generator

If you used the Microsoft provided generator to set up the Office Add-in, it is as simple as running the command below:

npm run validate

If you did not use the Yeoman generator

You need to take the extra step of installing the validation package first.

npm install -g office-addin-manifest
npm run validate

This step is well covered in the Microsoft documentation and is mostly here for completeness. But it does not actually report runtime errors, the kind of errors that otherwise silently occur and lead to menus, icons, and buttons not showing up.

2. Determining what errors might be causing it not to render properly

Unfortunately, when you Google for ways to debug the manifest file, it usually points you to the aforementioned validator, which is helpful but does not come close to solving actual bugs in the manifest that might cause your desired UI components to just not appear. It took me several days to figure out how you debug a syntactically correct but broken manifest file, which was a motivation for writing this post.

This debugging methof generates a runtime log for the manifest.xml of the errors that it encountered:

Open the Registry Editor on Windows. You can just search for it in the search bar and the logo looks like that.
Navigate to HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Wef\Developer\.
Add a key called RuntimeLogging to Developer. To do that, just right click on the Developer folder and choose New and then Key.
Click on RuntimeLogging and then double click on (Default) in the box to the right.
Add the path to the .txt file where you want the log messages to be written. If you have not created a file for that, go and create one. That path should include the file name.
Run the Add-in however you normally would in your development environment. As far as I know, it requires no special flags or parameters in any configuration.
After the Add-in has loaded in Office, you can check the designated file for any useful log messages.

Happy debugging!