-
simply add job type "group" where one would be able to select all existing jobs, after run we would have single main build view and it would have a section with "sub-builds"; for example https://code.onedev.io/onedev/server/~builds/5303 this would likst all resulting artifacts and it would have tab "builds" and list the actual executed builds and their status.
Job dependency can be used for this purpose. You may configure the "group" job to depend on other "sub" jobs and retrieve artifacts from them.
-
Job dependency can be used for this purpose. You may configure the "group" job to depend on other "sub" jobs and retrieve artifacts from them.
Would it be possible to only have the "group" job listed on main page somehow?
-
Would it be possible to only have the "group" job listed on main page somehow?
Unfortunately no.
-
Previous Value Current Value Open
Closed
| Type |
Question
|
| Priority |
Normal
|
| Assignee | |
| Labels |
No labels
|
Summary
I would like to have a single build for any given commit/tag/release that would run and include various artifacts. I'm trying to build a kotlin-native project that creates binary for windows/linux/mac and mobile ios/android. Each build requires different runner and slightly different command execution.
Examined solutions
I found matrix build (https://docs.onedev.io/tutorials/cicd/matrix-build) and it felt like a good solution but when I tried to configure it I realised it's not a good fit - in the end I don't want to have a matrix in this case, more like a tabular set of all parameters thus something more akin of group of builds.
Supposedly there is #1220 but I think I would have to exclude overwhelming majority of the combinations.
Proposals
simply add job type "group" where one would be able to select all existing jobs, after run we would have single main build view and it would have a section with "sub-builds"; for example https://code.onedev.io/onedev/server/~builds/5303 this would likst all resulting artifacts and it would have tab "builds" and list the actual executed builds and their status.
"matrix build" where one would simply define tuples of all parameters, for example:
widows-executorwindows-specific-build-commandlinux-executorlinux-android-imagelinux-specific-build-commandlinux-executorlinux-android-imageandroid-specific-build-commandmac-executorios-specific-build-commandmac-executormacos-specific-build-commandI think that (1) would be way better in this case