How to make new xPack Windows Build Tools releases
This page is intended for those who maintain the xPack Windows Build Tools project and documents how to make new releases.
Prerequisites
The Windows binaries are compiled on x64 GNU/Linux, using mingw-w64.
For details on installing the prerequisites, please read the XBB prerequisites page.
Get project sources
The project is hosted on GitHub:
To clone the stable branch (xpack
), run the following commands in a
terminal (on Windows use the Git Bash console):
rm -rf ~/Work/xpack-dev-tools/windows-build-tools-xpack.git && \
git clone https://github.com/xpack-dev-tools/windows-build-tools-xpack.git \
~/Work/xpack-dev-tools/windows-build-tools-xpack.git
For development purposes, clone the xpack-development
branch:
rm -rf ~/Work/xpack-dev-tools/windows-build-tools-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
--branch xpack-development \
https://github.com/xpack-dev-tools/windows-build-tools-xpack.git \
~/Work/xpack-dev-tools/windows-build-tools-xpack.git
Or, if the repo was already cloned:
git -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git pull
Get the writable helper sources
The project has a dependency to a common helper, that is
normally installed as a read-only dependency; for development
purposes, to be able to make changes to the scripts located inside the helper,
clone the xpack-development
branch and link it to
the user global xPacks store:
rm -rf ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
mkdir -p ~/Work/xpack-dev-tools && \
git clone \
--branch xpack-development \
https://github.com/xpack-dev-tools/xbb-helper-xpack.git \
~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git
Or, if the repo was already cloned:
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git
Other repositories in use are:
- none
Release schedule
This distribution generally follows the official GNU make releases, which are very rare, and the BusyBox tags.
Prepare the new releases
Before starting the build, perform some checks and tweaks.
Download the build scripts
The build scripts are available in the build-assets/scripts
folder of the
xpack-dev-tools/windows-build-tools-xpack
Git repo.
To download them on a new machine, clone the xpack-development
branch,
as seen above.
Check Git
In the xpack-dev-tools/windows-build-tools-xpack
Git repo:
- switch to the
xpack-development
branch - pull new changes
- if necessary, merge the
website
branch
This is really important, otherwise the next steps will build again the previous release!
The xpack
branch should be unchanged since the previous release
and will be updated when the new release is out.
Update helper & other dependencies
Check the latest versions at https://github.com/xpack-dev-tools/ and
update the dependencies in build-assets/package.json
.
Increase the version and update it in the top package.json
- determine the version (like
4.4.1-3
) - update the version in top
package.json
- use the new version, suffixed by
.pre
, like4.4.1-3.1.pre
.
Update the customFields
in build-assets/package.json
(if necessary)
If the project uses customFields
in build-assets/package.json
,
update them.
Start the local web server
Execute the npm script clean
then start
in the website sub-project,
or run the following in a terminal:
(cd ~/Work/xpack-dev-tools/xbb-helper-xpack.git/website; npm run clean; npm run start)
Navigate to the Maintainer Info page, the Update the version specific code section.
Increase the version and update VERSION
Determine the version (like 4.4.1-3
)
and update the build-assets/scripts/VERSION
file; the format
is 4.4.1-3
.
The fourth number is the xPack release number of this version. A fifth number will be added to the version in `package.json` when the package is published to the `npm` server.
Check the latest upstream release
GNU Make
The latest releases must have been announced in GNU Make releases.
Compare the latest upstream release with the latest xPack release. If necessary, update the triplet, otherwise increase the fourth number, as below.
BusyBox (Windows fork)
The Windows fork of the BusyBox project doesn't have full releases, but the latest versions are tagged in the GitHub project (https://github.com/rmyorston/busybox-w32/tags).
When updating busybox, increase the fourth version number.
Update the customFields
(if necessary)
If the project uses customFields
in build-assets/package.json
- update the release specific properties (if any)
- restart the local web server
Update the version specific code
- open the
build-assets/scripts/versioning.sh
file - add a new
if
with the new version before the existing code
Fix possible open issues
Check GitHub issues and pull requests:
and fix them; assign them to a milestone (like 4.4.1-3
).
Update CHANGELOG.md
- open the
CHANGELOG.md
file - check if all previous fixed issues are in
- check the latest commits
xpm run git-log
; if necessary, copy/paste lines, group by dates and edit them using the below regular expressions - add a new entry like * v4.4.1-3 prepared
- commit with a message like prepare v4.4.1-3
To turn the dates into headings, change from:
([0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]) [*]
to:
## $1
*
To remove the rest of the dates, change from:
^[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9] [*]
to:
*
Push the changes to the xpack-development
branch
Be sure that the latest commit that updates VERSION
is pushed
to the xpack-development
branch!
This is really important, otherwise the next steps will build again the previous release!
Run the development builds
The build currently runs on the x64 GNU/Linux machine.
Before the real build, run a test/development build.
Visual Studio Code extension
All actions are defined as xPack actions and can be conveniently triggered via the VS Code graphical interface, using the xPack C/C++ Managed Build Tools extension.
Patches
This project uses the upstream sources, without patches.
Restart the docker daemons
If, for any reasons, the docker builds need to be canceled, it is very likely that some processes will continue to run in the background.
To completely terminate them, and ensure that docker runs from a clean slate, restart the docker daemons on all GNU/Linux machines:
sudo systemctl restart docker
Check if both projects are pushed
Check if both the current project and the helper are
on the xpack-development
branch and the latest
commits are pushed to GitHub.
Build the x64 Windows binaries
Run the docker build on the production machine (xbbli
);
start a VS Code remote session, or connect with a terminal:
caffeinate ssh xbbli
To check the available space:
xpm run check-space -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
To free the space used by all previous builds of all xpack-dev-tools
packages:
xpm run clear-all-project-builds -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
To update the build scripts and build the development binaries:
rm -f ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets/package-lock.json && \
git -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
git -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpack-dev-tools/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
\
xpm run deep-clean --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
xpm run docker-link-deps --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
xpm run docker-build-development --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
Several minutes later, the output of the build script is a compressed
archive and its SHA signature, created in
the buils-assets/build/win32-x64/deploy
folder:
-
xpack-windows-build-tools-4.4.1-3-win32-x64.zip
-
xpack-windows-build-tools-4.4.1-3-win32-x64.zip.sha
To update the build scripts and build the release binaries:
rm -f ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/package-lock.json && \
git -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git pull && \
xpm run install -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
\
xpm run deep-clean --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets && \
xpm run docker-build-development --config win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
Update the trees in the Install Guide page
Copy the trees displayed at the end of the test builds and paste to Folder hierarchy section in the web file:
website/docs/install/_miscellaneous.mdx
If present, replace the actual version (like 4.4.1-3) with the following expression:
${customField('xpackVersion')}
macOS does not have a tree
command; either compile it from
sources, or install it
via HomeBrew, and make a link to /usr/local/bin
.
Update the list of links in top package.json
Copy/paste the full list of links displayed at the end of the build, in sequence, and check the differences compared to the repository.
Commit if necessary.
Update the durations of the development builds
In website/docs/maintainer/_development-durations.mdx
, update
the durations of the builds.
Commit if necessary.
How to build a debug version
In some cases it is necessary to run a debug session with the binaries.
For these cases, the build script accepts the --debug
options.
There are also xPack actions that use this option (build-development-debug
and docker-build-development-debug
).
Files cache
The XBB build scripts use a local cache such that files are downloaded only during the first run, later runs being able to use the cached files.
However, occasionally some servers may not be available, and the builds may fail.
The workaround is to manually download the files from alternate
locations (like
https://github.com/xpack-dev-tools/files-cache/tree/master/libs),
place them in the XBB cache (Work/cache
) and restart the build.
Run the production builds
The automation is provided by GitHub Actions and three self-hosted runners.
Start the self-hosted runners
- on the development machine (
wksi
) open a ssh session to the build machinexbbli
:
caffeinate ssh xbbli
Create a screen
session, to provide a persistent standard output for
the runners:
screen -S ga
To quit it, use # Ctrl-a Ctrl-d
.
For xbbli
, which has more memory, start two runners:
~/actions-runners/xpack-dev-tools/1/run.sh &
~/actions-runners/xpack-dev-tools/2/run.sh &
To check the status of the runners locally:
ps -a | grep 'Runner.Listener'
To kill them:
killall Runner.Listener
Check the status of the runners
The status of all self-hosted runners is available at the GitHub Runners page.
Publish the helper
Publish a new release of the helper on npmjs.
Update the dependency to the new helper
In build-assets/package.json
, update the reference
to "@xpack-dev-tools/xbb-helper":
(possibly in all xPack projects).
Commit the changes to build-assets/package.json
Use the message build-assets/package.json: bump deps.
Check for disk space
Check if the build machines have enough free space and eventually do some cleanups:
xpm run check-space -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
This is equivalent to running a df
command.
- GNU/Linux
df -BG -H /
To free the space used by all previous builds of all xpack-dev-tools
packages:
xpm run clear-all-project-builds -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
This is equivalent to running a wide rm
to remove the build
folders:
rm -rf ~/Work/xpack-dev-tools/*/build-assets/build
Generate the GitHub workflows
Run the generate-workflows xPack action to update the GitHub workflow files.
xpm run generate-workflows -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
Commit and push
- commit with the message Re-generate workflows
- push the
xpack-development
branch to GitHub
Manually trigger the build GitHub Actions
To trigger the GitHub Actions builds, use the xPack actions:
- trigger-workflow-build-win32-x64
xpm run trigger-workflow-build-win32-x64 -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
The scripts behind these actions require the GITHUB_API_DISPATCH_TOKEN
variable to be present
in the environment, and the organization PUBLISH_TOKEN
to be visible in the
Settings → Action →
Secrets
page.
These commands use the xpack-development
branch of this repo.
Durations & resulting binaries
The build takes several minutes to complete.
The workflow results and logs are available from the GitHub Actions page.
Update the values in website/docs/maintainer/_github-actions-durations.mdx
with those shown by GitHub Actions.
The resulting binaries are available for testing from pre-releases/test.
Run the tests
Automated tests
The automation is provided by GitHub Actions.
To trigger the GitHub Actions tests, run the xPack actions:
- trigger-workflow-test-prime
xpm run trigger-workflow-test-prime -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
The scripts behind these accesible require the GITHUB_API_DISPATCH_TOKEN
variable to be present
in the environment.
These actions use the xpack-development
branch of this repo and the
pre-releases/test
binaries.
The tests results are available from the GitHub Actions page.
After running the prime tests, download the test results and compare with previous runs.
Manual tests
To download the pre-released archive for the specific platform and run the tests, use:
git -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git pull
xpm run install -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
xpm run test-pre-release -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
For even more tests, on each platform, download the archive from pre-releases/test and check the binaries.
Publish the release
Create a new GitHub pre-release
- in
CHANGELOG.md
, add the release date and a message like * v4.4.1-3 released - commit with CHANGELOG update
- check and possibly update the
build-assets/templates/body-github-release-liquid.mdx
- push the
xpack-development
branch to GitHub - run the trigger-workflow-publish-release xPack action:
xpm run trigger-workflow-publish-release -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
The workflow result and logs are available from the GitHub Actions page.
The result is a draft pre-release tagged like v4.4.1-3 (mind the dash in the middle!) and named like xPack Windows Build Tools v4.4.1-3 (mind the dash), with all binaries attached.
- edit the draft and be sure it is attached to the
xpack-development
branch (important!) - perform the final edits (maintenance vs. new release) and check if everything is fine
- keep the pre-release button enabled
- do not enable Discussions yet
- click the Publish release button
Note: at this moment the system should send a notification to all clients watching this project.
Prepare a new blog post
- check and possibly update the
website/blog/_templates/blog-post-release-part-[12]-liquid.md
- run the generate-website-blog-post xPack action;
this will add a file in the
website/blog
folder:
xpm run generate-website-blog-post -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
- edit the front matter properties
- select the correct summary
- commit with blog post release 4.4.1-3 published
Update the web install page
- check and possibly update the output of the
--version
runs inwebsite/docs/install/_automatic-install-quick-test.mdx
website/docs/install/_manual-install-quick-test.mdx
- commit changes
Check the list of links in top package.json
- open the
package.json
file - check if the links in the
bin
property cover the actual binaries - if necessary, also check on Windows
Update the package.json list of binaries
- select the
xpack-development
branch - be sure that the binaries were attached to the pre-release
- run the update-package-binaries xPack action:
xpm run update-package-binaries -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
- open the top
package.json
file - check the
baseUrl:
it should match the file URLs (including the tag/version); no terminating/
is required - from the release, check the SHA & file names
- compare the SHA sums with those shown by
cat *.sha
- check the executable names
- commit all changes, use a message like package.json: update urls for 4.4.1-3.1 release
Publish on the npmjs.com server
- select the
xpack-development
branch - check the latest commits
xpm run git-log
- update
CHANGELOG.md
, add a line like * v4.4.1-3 published on npmjs.com - commit with a message like CHANGELOG: publish npm v4.4.1-3.1
npm pack
and check the content of the archive, which should list only thepackage.json
, theREADME.md
,LICENSE
andCHANGELOG.md
; possibly adjust.npmignore
- configure the version; the first 4 numbers are the same as the GitHub release; the fifth number is the npm specific version:
npm version 4.4.1-3.1
- the commits and the tag should have been pushed by the
postversion
script; if not, push them withgit push origin --tags
to GitHub - publish and add the
test
tag:
npm publish --tag test
- when publishing for the first time, use:
npm publish --access public
After a few moments the version will be visible at npmjs.com.
Test if the binaries can be installed with xpm
Run the trigger-workflow-test-xpm xPack action:
xpm run trigger-workflow-test-xpm -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
This will install the package via xpm install
on all supported platforms.
The tests results are available from the GitHub Actions page.
Tag the npm package as latest
When the release is considered stable, promote it as latest
:
npm dist-tag ls @xpack-dev-tools/windows-build-tools
npm dist-tag add @xpack-dev-tools/windows-build-tools@4.4.1-3.1 latest
npm dist-tag ls @xpack-dev-tools/windows-build-tools
In case the release proves problematic and needs to be unpublished:
npm unpublish @xpack-dev-tools/windows-build-tools@4.4.1-3.1
Build the static website locally
Validate the web site content in a local build via the npm build
script:
npm --prefix website run build
Publish the website
- merge
xpack-development
intowebsite
- push the
website
branch to GitHub
At this moment an automated GitHub Action will generate and publish the website.
- the new release blog post is in https://xpack-dev-tools.github.io/windows-build-tools-xpack/blog/
- remember the post URL, since it must be used to update the release page and the X/Twitter announcement
The website
branch may be subsequently updated, as long as the
version in package.json
is not changed.
Update the xpack
branch
- merge
xpack-development
intoxpack
- push the
xpack
branch to GitHub
Avoid further updates to the xpack
branch until the next release.
Create the final GitHub release
- go to the GitHub Releases page
- check the download counter, it should match the number of tests
- add a link to the Web blog
[Continue reading »]()
; use an same blog URL - remove the tests only notice
- disable the pre-release button
- click the Update Release button
Check SourceForge mirror
Cleanups
Remove the pre-release binaries
- go to https://github.com/xpack-dev-tools/pre-releases/releases/tag/test/
- remove the test binaries
Clean the work area
Run the trigger-workflow-deep-clean xPack action
xpm run trigger-workflow-deep-clean -C ~/Work/xpack-dev-tools/windows-build-tools-xpack.git/build-assets
This will remove the build folders on all self-hosted runners.
The results are available from the GitHub Actions page.
Share on Twitter
- in a separate browser windows, open X/Twitter
- using the
@xpack_project
account - paste the release name like xPack Windows Build Tools v4.4.1-3 released
- paste the link to the blog post release
- click the Tweet button
Analytics
- GitHub
xpack-dev-tools/windows-build-tools-xpack
repo- latest xPack release
- all xPack releases
- individual file counters (grouped by release)
- npmjs.com
@xpack-dev-tools/windows-build-tools
xPack
Credit to Shields IO for the badges and to Somsubhra/github-release-stats for the individual file counters.