jbauer opened 2 years ago
|
|||||
How about importing step templates from a common project? Another approach is to define a common job in common project with steps and caches parameterized, and then import the common job in different projects and have a downstream job depending on this common job with desired parameter values. |
|||||
Hm that might work, although a bit hidden. I just tried it as administrator but OneDev complains about missing code read permissions on the project I want to import the steps from. So I selected the buildbot ssh private key (which has code read on everything and used by build jobs) but then OneDev says the private key is invalid AND prints the private key into the error message! So I guess something is broken? |
|||||
Even if you are login as administrator, the job itself has to run in the background requiring permission to import from other projects. This is something like root user still need to give a OS process permission explicitly to access system resources. The secret has to contain value of an access token instead of private key, as explained in inline help of the build spec import page. The access token value should not printed in error message though. I will create a bug report to track this. |
|||||
Also check this tutorial for CI/CD reuse: https://medium.com/nerd-for-tech/ci-cd-configuration-reuse-in-onedev-c8110b709614 |
|||||
Robin Shen changed state to 'Closed' 2 years ago
|
|||||
Sorry for coming back late but I was busy with other things. I have taken a look at importing build settings from a common project but I still feel like some things are hidden or missing.
So the main issue is that jobs in a common project are not adjustable. Allowing properties/parameters in more job settings can help but treating an imported job as a template that can be modified as needed would be great. However that would need to keep track of what has been modified so that modified settings are not overriden when updating the original, imported job. |
|||||
jbauer changed state to 'Open' 2 years ago
|
|||||
Robin Shen changed state to 'Closed' 2 months ago
|
|||||
Caches are now steps which can be shared via step templates. Resource requirements moved to job executors which is no longer applicable for this topic. And most other job settings can be adjusted via variables. |
Type |
Improvement
|
Priority |
Normal
|
Assignee |
Hi,
Having a large number of Java projects you often end up defining the same things in build spec over and over again especially if all these projects are built using the same build tool, e.g. Gradle or Maven.
Common groups of build steps:
Common Java cache folders for such projects:
It would be great if we could define global templates for build steps and cache configuration. So given the example above you would have global step templates named
Initialize
(having 3 steps) andRun Tests
(having 2 steps) and I can reuse them in any job. I could even imagine that global step templates can include other global step templates, so that aCI
step template could include theInitialize
andRun tests
templates. Having such global templates would also make it easier to change the behavior of many builds by simply updating the global step template.Same with caches. The above example could be stored as a global cache config named "Gradle/Maven build cache" and then reused everywhere.