Hooks are specified in the .git/hooks directory. That’s great, a git repository is completely contained within its parent folder, you can copy it somewhere else and all of the code, history and config come with it.
It’s not so convenient if you want to create some hooks that apply across multiple repositories though. You can just copy your hook files between all of your repos, or it turns out that there is a smarter way. Git config has a core.hookspath key. You can create a folder somewhere with the hooks that you want to apply to all repos and set this key.
Use git config --global to set the value of a key in the global config file and git config --global --list to list the config keys and their current values.
git config --global core.hookspath '<path to hooks directory>'
It’s Summer (at least in the northern hemisphere), hooray. You’ve booked some time off, wrapped up what you were working on as best you can, committed and pushed all your code, set your out-of-office and switched off Teams. Beautiful.
When you come back you flick through your messages to catch back up. What’s this? Some muppet commented out some vital code and pushed their changes? Who? Why?
It happens happened. That muppet was me.
There are good reasons why you might remove or add some code in your local environment but it is really important that those changes don’t end up in anyone else’s copy.
You can either:
Plan A: back yourself never to accidentally commit and push those changes
Plan B: add a pre-commit Git hook as an extra line of defense
Open the (hidden) .git folder inside your repository and rename pre-commit.sample to pre-commit.
As the comments at the top of the file say, if you want to stop the commit then this script should echo some explanatory comment and return non-zero. This is mine:
if git diff --staged | grep 'DONOTCOMMIT' -qE; then
echo "Your staged changes include DONOTCOMMIT"
exit 1
fi
Before committing, Git looks for a pre-commit file in the hooks folder and executes it if it finds it.
git diff --staged gets a string of the changes which are staged i.e. going to be included in this commit. This string is piped to grep to match a regular expression – I’m keeping it simple and searching for the string ‘DONOTCOMMIT’ but you could get fancier if you wanted.
If DONOTCOMMIT is found in the staged changes then a message to that effect is shown and the scripts exit with 1 (which tells Git not to continue with the commit).
VS Code error dialog thrown by pre-commit hook
Next time I add or remove some code that is for my eyes only I’ll add a //DONOTCOMMIT comment alongside to remind me to undo it again when I push the code.
This post is going to be a bit of a brain dump about developing my VS Code extension, branching strategy for pre-releases and releases and using GitHub actions to stitch it all together.
If you’re only here for the AL / Business Central content then you might want to give this one a miss. Then again, Microsoft are increasingly using GitHub for AL projects themselves (e.g. AL-Go for GitHub) – so it might be worth a look after all.
Objectives
What am I trying to achieve? I want to have a short turn around of:
Have an idea for a new feature
Implement the feature
Test it and make it available for others to test
Release
I use the extension pretty much every day at work so I am my own biggest customer. I want to write some new feature and start working with it in a pre-release myself to find any issues before I release it.
I also want to have a little fun with a side-project – learn a little typescript, practice some CI/CD, GitHub Actions and Application Insights. If anyone else finds the extension useful as well then that’s a bonus.
Overview
This is my workflow. I want to get the feature into the pre-release version of the extension on the marketplace quickly. That way I will get the new pre-release myself from the marketplace and use it in my daily work. I’ll make any fixes or improvements in updates to the pre-release before merging the code to the release version and publishing to the marketplace.
GitHub Actions
The GitHub actions definition is fairly self-explanatory. The yaml is bellow, or here if you prefer. Run whenever some code is pushed. Build, test, package with npm and vsce. Run the PowerShell tests with Pester. Upload the built extension as an artifact. If the pre-release branch is being built then use vsce to publish to the marketplace with the --pre-release switch.
The actions definition in the master branch is similar but publishes to the marketplace without the --pre-release switch.
name: CI
# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
push:
pull_request:
branches: [ master ]
workflow_dispatch:
jobs:
build:
runs-on: windows-latest
steps:
# Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
- uses: actions/checkout@v2
- name: npm install, build and test
run: |
npm install
npm run build
npm test
- name: package with vsce
run: |
npm install -g vsce
vsce package
- name: run pester tests
shell: pwsh
run: |
Set-PSRepository psgallery -InstallationPolicy Trusted
Install-Module Pester
Install-Module bccontainerhelper
gci *ALTestRunner.psm1 -Recurse | % {$_.FullName; Import-Module $_.FullName}
Invoke-Pester
- name: Upload a Build Artifact
uses: actions/upload-artifact@v2.1.4
with:
name: AL Test Runner
path: ./*.vsix
- name: Publish to marketplace
if: github.ref == 'refs/heads/pre-release'
run: |
vsce publish -p ${{ secrets.VSCE_PAT }} --pre-release
The personal access token for my Visual Studio account (used to publish to the marketplace) is stored in a repository secret.
It is rewarding to make some changes to the extension, push them to GitHub and then 10-15 minutes later be able to use them in a new version of the extension which has been automatically published, downloaded and installed. It allows you to publish more frequently and with more confidence.
function List-Commits {
cd 'C:\Git'
$Commits = @()
Get-ChildItem . -Directory | % {
cd "$_"
if (Test-Path (Join-Path (Get-Location) '.git')) {
$Commits += git log --all --format="$($_)~%h~%ai~%s~%an" | ConvertFrom-Csv -Delimiter '~' -Header ('Project,Hash,Date,Message,Author'.Split(','))
}
cd ..
}
$Commits | ? Author -EQ "$(git config --get user.name)" | sort Date -Descending | Out-GridView -Title 'Commits'
}
This function iterates through Git repositories under the same parent folder (C:\Git in my case), builds a list of all the commits that you’ve authored (i.e. that match your user.name in Git config) and displays them in descending date order in a grid view.
Change the path in the second line to suit, or just remove it to have it search for repositories under the current directory.
Sample output in a PowerShell grid view
I use it to remind myself what I’ve been working on over the last few days. Mostly for fun and only occasionally because I’m late filling in my timesheets… 🙄
If you occasionally glance at my blog you might have noticed that I am a big fan of pull requests as served up by Azure DevOps (exhibit A). I briefly described our typical branching strategy here, including how and why we use pull requests.
I love it. Writing, testing and reviewing discrete pieces of development independently of one another helps spread the work around the team and prevent work getting blocked by some unrelated development in the same project.
However, occasionally we’ll have several pull requests open for the same project which I want to publish to some testing environment (either a local Docker container or SaaS sandbox) all together. Maybe it made sense to develop those work items separately but it’s hard to test them in isolation.
I tend to create a new local branch called testing or something equally banal, merge all the changes into that branch and publish. Here’s where the octopus comes in. We usually use git merge to merge a single other branch into the current branch e.g.
To merge the commits in the release branch into the master branch (but only if it is possible to fast-forward merge).
Git doesn’t restrict you to a single other branch though. You can add as many as you like. Say we’ve got 3 feature branches on the go which I want to push to a SaaS sandbox for a consultant to test.
James Pearson 