6 points | by zdw 3 days ago ago
4 comments
Don't like this since it's just asking for code conflicts with any other developer's code and their own build number changes.
I prefer setting the number on the CD pipeline. It's one less file to have changes in git.
I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective.
Preferably you'd have a build server where you can use the build number. I use this to build my macOS application in GitHub Actions.
[[ $GITHUB_REF_TYPE = "tag" ]] && MARKETING_VERSION=$GITHUB_REF_NAME || MARKETING_VERSION=$(git rev-parse --short HEAD) echo "Building $MARKETING_VERSION ($GITHUB_RUN_NUMBER)" agvtool new-version -all $GITHUB_RUN_NUMBER agvtool new-marketing-version $MARKETING_VERSION
Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.
Don't like this since it's just asking for code conflicts with any other developer's code and their own build number changes.
I prefer setting the number on the CD pipeline. It's one less file to have changes in git.
I disagree that a timestamp is a “build number”. Additionally, injecting dates/times into builds is bad juju from a reproducibility perspective.
Preferably you'd have a build server where you can use the build number. I use this to build my macOS application in GitHub Actions.
Non-tagged build gives me "Building a3d4743 (54)", tagged build gives me "Building 0.3.1 (55)".Agreed, CI-managed build numbers are a good way of handling this. I've done the same thing at my past handful of jobs.