The source project of this merge request has been removed.
Container image & CI
Container image
Closes #3 (closed)
Used fancy ONBUILD
instructions to allow local and CI builds:
- When BUILD_ENV is set as
local
(which is the default value), the ZCure binary is built as part of the image constrution process - When it is set to
ci
, the builder expects binaries to live in$contextdir/bin
(e.g.dotnet publish -c Release -r linux-musl-x64 -o ${PWD}/bin
)
This makes it possible to use the same Dockerfile for CI pipelines (where binaries are built & published) and local development.
Also opted to use MS' alpine-flavored dotnet/runtime
image, think it's appropriate enough?
Finally, I'm not 100% the entire set of files created by dotnet publish
is actually necessary, since I don't know a thing about dotnet haha.
CI
Closes #2 (closed)
Added build, release and containerize jobs
- Build produces artifacts for
linux-x64
,linux-musl-x64
(for the container image) andwin-x64
- Made it so that it's possible to plug in new architectures very easily by simply duplicating the
.build:zcure
job - Could potentially be controlled by adding a var like
BUILD_WIN-X64
- Produces Debug builds for dev/beta and Release builds for main
- Made it so that it's possible to plug in new architectures very easily by simply duplicating the
- Release relies on similar mechanisms as the modules, each architecture's binaries get dynamically added to assets
- Containerize job uses the Dockerfile described above with Kaniko (no DinD involved) and the tag chosen by semantic-release
Edited by alt