xpack-dev-tools / openocd-xpack

A binary distribution of OpenOCD
https://xpack-dev-tools.github.io/openocd-xpack/
MIT License
345 stars 57 forks source link

Switch all builds to use Github-hosted runners #19

Closed maxgerhardt closed 2 years ago

maxgerhardt commented 2 years ago

Description

This is an extension to #18 for other operating systems.

The current Github Action files in this repository (.github/workflows/build.yml) all require self-hosted runners to be able to execute.

https://github.com/xpack-dev-tools/openocd-xpack/blob/461b1278437d5a1ad99481e87ccaa7b5e6e535b8/.github/workflows/build.yml#L34-L37

This is an unnecessary complication if the goal is to just obtain binaries for a given OpenOCD repository. As showcased in #18, switching from the requirement of a self-hosted Linux runner machine to the Github-provided ubuntu-latest runner provides a successful build for Linux + Windows with the x86 and x64 architectures as well.

In particular, the following changes should be made:

Steps to Reproduce

  1. Fork this repo
  2. Take a look at the .github/workflows/build.yml and related files
  3. Attempt a build

Expected behaviour: The build executes without having the need for self-hosted runners.

Actual behaviour: Nothing happens if the account does not have these special self-hosted runners set-up.

Versions

ilg-ul commented 2 years ago

Hi Maximilian,

Although you managed to run the Intel Linux OpenOCD build on the GitHub hosted runners, this solution does not apply to all my binary xPacks, since the toolchain builds take much longer to complete than the GitHub runners allow. Not to mention that the XBB Docker images are huge, and you have to download them for every build.

As for the Arm builds, you are right, you can use a cross compiler on an Intel machine, but the current build scripts also run tests with the generated binaries, and executing the Arm binaries on an Intel machine is not trivial, it requires an emulator; this not only increases the complexity of the build process, but also may introduce subtle differences, making the solution less trustworthy.

Plus that the Arm build script must be executed in an environment with a specific version of GLIBC and possibly other system libraries, which is not trivial to replicate in a cross environment.

So, thank you for your feedback, and feel free to suggest improvements to the build processes, but for now I don't think that using the GitHub runners is a realistic option.