Tasks
This week, for the Starchart project, I added some explanation to how to create releases in GitHub repo, and I added some tests too.
I wanted to mention how to create releases because I noticed multiple people have been asking how to do it. It seems like a good idea to add some pointers in the wiki.
As for test, thing are quite usual except one interesting bug I found. (PR)
Create GitHub Releases
This is about making a release version of your application from your GitHub repo, in the repo's release page. This will generate copies of the source code for download, in the release.
GitHub has documentation on how to manage releases, including creating one.
The Page to create a release looks like this:
Assuming you have the access, you do it by:
- Click "Releases" on a repo's main page, then click "Draft a new release" to get to the page shown.
- Choose or create a tag, which can be a version.
- Choose a branch, which might be main.
- Give it a title and some description of what's added/changed. You can click "Generate release notes" to get some information from GitHub, including contributors, change log, and newly committed PRs.
- You can set it as pre-release or latest release. You can even allow discussion under the release note. 6.(Optional) You can attach some files to the release.
As part of making a release, you might increment project version for a release. You can use CLI command npm version
in the project directory.
For example, assuming you have initialized npm and git, npm version 0.8.0 -m "sample commit"
will change the version in package.json
and create a new commit with the commit message sample commit
by -m
option. This new commit will have a tag v0.8.0
, which you can use for creating a release.
NOTE: locally created tags don't exist on GitHub repo unless you push them. To push the commit with the tag, you can push
with --tags
flag, such as git push origin main --tags
. For more information on tags, see here.
Odd Bug
While writing a test, I noticed an odd behavior when I tested this code:
export function setIsReconciliationNeeded(
reconciliationNeeded: SystemState['reconciliationNeeded']
) {
try {
return prisma.systemState.update({
data: { reconciliationNeeded },
where: { unique: StateEnumType.unique },
});
} catch (error) {
return initialize();
}
}
The code is meant to update a row in the SystemState
table, to set reconciliationNeeded
field by the parameter, which is Boolean (True/False). It uses Prisma's Update
function to do the update.
The main and interest point is that this try
block will not catch errors throw by [Update
] when it fails to find such row, such as when it simply doesn't exist.
Given that the documentation states the function returns the exception when it can't find the target to update, my guess was that it's returning the error from the function with the return
keyword, which makes the error land outside of the try
block.
The expected behavior is to catch the error and then call and return initialize
.
Therefore, I tried to avoid having return in the try
block by doing it later:
export async function setIsReconciliationNeeded(
reconciliationNeeded: SystemState['reconciliationNeeded']
) {
let result;
try {
result = await prisma.systemState.update({
data: { reconciliationNeeded },
where: { unique: StateEnumType.unique },
});
} catch (error) {
return initialize();
}
return result;
}
This way, the try
block properly catches the error and execute the catch
block.
Alternatively, a teammate come up with another solution:
export function setIsReconciliationNeeded(
reconciliationNeeded: SystemState['reconciliationNeeded']
) {
return prisma.systemState
.update({
data: { reconciliationNeeded },
where: { unique: StateEnumType.unique },
})
.catch(() => {
return initialize();
});
}
This one instead deal with the error before the code hits return
. The error is caught in catch
and dealt with, before anything goes to return
.
Top comments (0)