Default 'Hide whitespace' can significantly save your time on reviewing. Many many developers have asked for this feature for a long time, but GitHub still doesn't officially support it. You don't have to wait.
This small browser extension GitHub Whitespace comes to rescure!
TLDR;
The solution is git push -u
David.Wei @ /d/git/xemt-core/dfx - [feature/mt-38546-axo] $ git push -u
branch 'feature/mt-38546-axo' set up to track 'origin/feature/mt-38546-axo'.
Everything up-to-date
David.Wei @ /d/git/xemt-core/dfx - [feature/mt-38546-axo] $ gh pr view
MT-38546 Fintrac API| DFX DB changes #1355
Open • David-Wei_euronet wants to merge 6 commits into integration from feature/mt-38546-axo • about 3 days ago
...
vilmibm wrote the following on this issue and it reminds me why I couldn't find the PR:
gh pr view
relies on mapping the current locally checked out branch to a remote tracking branch so that the github host can be queried appropriately for PR data; in your example it seems like you're creating PRs without any configured tracking information, making it impossible for gh to open the PR.
To avoid this issue happening in the future, you can run the following command to enable the auto tracking feature.
git config --global push.autoSetupRemote true
If your git version is lower and couldn't upgrade easily, another measure is to create an alias like the following
git config --global alias.p 'push -u origin HEAD'
Then always use git p
instead of git push
will do the trick.
Today, I created another workflow file to deploy my side project to the production environment. Here's a simple memo for what I have done.
-
Setup a new domain name on <cloudflare.com>
-
Setup a GitHub runner on the target VPS (this step is not really necessary, I can use an existing runner, but then I'll need to cope with coping built result to the target VPS )
-
Setup the runner as a service, in the runner folder, run
sudo ./svc.sh install
sudo ./svc.sh start
-
Create a work-flow file in the .github/workflow
folder, and set
on:
workflow_dispatch
-
Manually run the work flow and deploy the project to the target place
-
Setup that project as a systemd service so we can easily restart it in the workflow file
For your reference, here the whole workflow file, and as I mentioned before, this article helped me a lot.
name: Deploy to the production env
# Controls when the workflow will run
on:
workflow_dispatch:
jobs:
deploy:
# Our previously created self-hosted runner
runs-on: [self-hosted, linux, racknerd]
strategy:
matrix:
dotnet: ["8.0.x"]
# A sequence of tasks that will execute as part of the job
steps:
# Checks out repository so our job can access it
- uses: actions/checkout@v4
- name: Setup .NET Core SDK ${{ matrix.dotnet-version }}
uses: actions/setup-dotnet@v4
with:
ref: ${{ github.event.inputs.tag }}
dotnet-version: ${{ matrix.dotnet-version }}
- name: Install dependencies
run: dotnet restore
- name: Build
run: dotnet build --configuration Release --no-restore
- name: Publish
run: dotnet publish -c Release --property:PublishDir=/a-target-folder/HappyNotes.Api
- name: Replace credentials
run: |
pwd
sed -i "s/password-placeholder/${{ secrets.PRODUCTION_MYSQL_PASSWORD }}/g" /a-target-folder/HappyNotes.Api/appsettings.json
sed -i "s/symmetric-security-key-placeholder/${{ secrets.PRODUCTION_SYMMETRIC_SECURITY_KEY }}/g" /a-target-folder/HappyNotes.Api/appsettings.json
sed -i "s/staging-happynotes-api.dev/happynotes-api/g" /a-target-folder/HappyNotes.Api/appsettings.json
- name: Restart the app
run: |
echo $XDG_RUNTIME_DIR
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user restart HappyNotes.Api.service
Have you ever seen weird indentations when doing code review? Mostly, the cause is that GitHub's default TABSIZE setting is 8 instead of 4 while some old code uses TAB for indentation. Fortunately, we can easily fix it by change this setting. 8 is not an ideal default TABSIZE nowadays, right? so it is all GitHub's fault!
Reference
This great article taught me how to use github actions to deploy my side project to my cheap VPS. Many thanks to the author!