#762  Allow globally reusable definition of cache folders and build steps
Closed
jbauer opened 3 weeks ago

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:

  • Initialize the build
    • checkout code
    • detect build version
    • set build version
  • Testing
    • run tests
    • publish test results

Common Java cache folders for such projects:

  • Gradle distributions downloaded by Gradle wrapper
  • JDKs downloaded by Gradle build toolchains
  • Gradle artifact cache
  • Maven artifact cache

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) and Run 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 a CI step template could include the Initialize and Run 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.

Robin Shen commented 3 weeks 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.

jbauer commented 3 weeks ago

How about importing step templates from a common project?

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?

Robin Shen commented 3 weeks ago

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.

Robin Shen commented 3 weeks ago
Robin Shen changed state to 'Closed' 3 weeks ago
Previous Value Current Value
Open
Closed
issue 1 of 1
Type
Improvement
Priority
Normal
Assignee
Issue Votes (0)
Watchers (4)
Reference
issue onedev/server#762
Please wait...
Page is in error, reload to recover