add generic bazel toolchain job#94
Conversation
|
I'm not sure what this is? Maybe this should be setup-bazel? As wrapping a simple bazel run doesnt seem worth it. It adds more complexity than just running it on command line. |
|
I started working on an autosd one but It felt to simple to be autosd specific. I could still try to force a config or container image to be autosd specific, instead of the generic one, if that makes sense. |
|
Where would you like to use this? Sorry, I dont get it yet. Workflow is called toolchain test. It sets up qemu. And the name is target-build. Thats three mismatching things :D |
|
@odra sorry this was stuck so long. Should we merge this with https://github.com/eclipse-score/cicd-workflows/blob/main/.github/workflows/qnx-build.yml? |
|
so was trying to create a job to run builds that use autosd's toolchain for different modules to use, let me update this patch with a new proposal (which I have conflicting opinions about its implementation) |
|
@AlexanderLanin I created a new "autosd-build.yml" workflow, which was my original intention. An example of the workflow usage can be found here: https://github.com/eclipse-score-fork-rh/rh-sample-autosd-toolchain/blob/main/.github/workflows/build-autosd.yml. It still requires modules to setup the toolchain in their MODULE.bazel files but it "injects" a bazelrc file with a specific config. My motivation is that I wanted to add autosd toolchain usage to N modules but I didn't want to "copy and paste" the same source code everywhere. |
Signed-off-by: Leonardo Rossetti <lrossett@redhat.com>
|
Thanks for the pull request. This thread has been quiet for 30 days, so we are marking it as stale for now. Please take a quick look and let us know whether it is still up to date, still relevant, needs review, or is ready to merge. Any new activity will remove the stale label automatically. If nothing changes in the next 10 days, we will close it to keep the backlog current. |
Changes
Sample Usage
It still requires modules to register toolchains as: