You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use github.com/tc-hib/go-winres and winres.json file to apply version details to Windows executables provided by this project.
Background
While this project currently does not provide Windows binaries as part of the normal release workflow, it may do so again in the future. Others may also wish to generate Windows binaries locally and could benefit from having version metadata embedded in the binaries for easier tracking and inventory management (e.g., SCCM deployments).
- Switch to semantic versioning (semver) compatible versioning pattern
- filenames (where applicable)
- embedded version metadata
- Generate RPM/DEB packages using nFPM
- "stable" release packages
- "dev" release packages
- provides binaries with `_dev` suffix in order to more easily
test the impact of new releases
- Add version metadata to Windows executables
- Use `github.com/tc-hib/go-winres` and `winres.json` file to apply
version details to Windows executables provided by this project
- update `.gitignore` to exclude Windows syso files
- these files are produced when running go generate as part of the
build process and should not be retained in version control
- Makefile: Compress binaries and use fixed filenames
- Makefile: Refresh recipes to add "standard" set, new package-related
options
- Build dev/stable releases using go-ci Docker image
- Add Dockerfile to provide "builder" image for Makefile-driven
release builds
- copy project/repo content into container at build time
- explicitly changing owner:group to `builduser`
- explicitly create new `builduser` user and group
- this is explicitly used for Docker-based builds
- set `/builds` as the working directory
- set Git `safe.directory` logic at system level
- Add new `.dockerignore` file to exclude unnecessary items from build
image generation
- Update Dependabot configuration to add update monitoring for
`go-ci-oldstable-build` image
- Update/Add Makefile recipes
- add separate docker/podman variants of container-based project
build recipes
- each uses slightly different logic to achieve rootless container
execution
- new recipes
- `docker-release-build`
- `docker-dev-build`
- `docker-packages`
- `podman-release-build`
- `podman-dev-build`
- `podman-packages`
- explicitly emit the tool used to perform specific tasks
- this can be useful to help explain why a generated builder image
does not appear in the `docker image ls` output as a sysadmin
might expect (if it was instead built with the `docker` command)
- rename/remove the helper build recipe from the `help` recipe
output (not useful to call directly)
- to explicitly run the build container as the `builduser` user that
is created during build image generation when using Docker to
build/run containers (Podman uses different settings)
- to send `xz` compressed output to stdout, then redirect to a
target file
- this works around failures to `chmod` and `chgrp` the compressed
copy of input files when run within a non-root container
- to explicitly bind mount the `release_assets` path into
`/builds/release_assets` (using the same Makefile variable)
read/write (instead of relying on implied read/write access)
- to explicitly use `/builds` as the working directory
- Update README
- note decompression step needed after downloading individual
binaries or building via some Makefile recipes
- note DEB and RPM packages as alternatives to downloading
individual binaries
This collection of changes allows reliably building this project using
either Docker or Podman via a "rootless" container.
refs GH-438
refs GH-439
refs GH-440
refs GH-441
refs GH-442
refs GH-443
Overview
Use
github.com/tc-hib/go-winres
andwinres.json
file to apply version details to Windows executables provided by this project.Background
While this project currently does not provide Windows binaries as part of the normal release workflow, it may do so again in the future. Others may also wish to generate Windows binaries locally and could benefit from having version metadata embedded in the binaries for easier tracking and inventory management (e.g., SCCM deployments).
References
The text was updated successfully, but these errors were encountered: