Migration from 0.x
The versions 0.x of the Seed plug-in are no longer supported actively and have been fully replaced by version 1.x.
The version 1.x remains 100% backward compatible with the setup you had done for the version 0.x. However, the existing plug-ins are now deprecated and should be replaced by the 1.x equivalent (see below).
The compatibility for version 0.x will be dropped with version 2.x.
The benefits of this new version are:
- no longer a need to configure a YAML file or configuration - the seed jobs contain directly their configuration, in a more explicit and manageable way
- it implies that the notion of project class no longer exists and is replaced by custom seed jobs which are fit to your different classes of projects to generate
After having upgraded from 0.x to 1.x, the Manage Jenkins will show data management errors:
You can safely discard them - some jobs generated by 0.x will have lost some information links to their parent seed.
Note that existing 0.x seed jobs will keep working, but I strongly recommend their migration since the configuration is in the end much simpler.
In the root seed jobs, the 0.x plugin Project seed generator step must be replaced by the Project folder generation step.
Its configuration is different:
- the project class does not exist any longer
- the corresponding YAML configuration to the project class must be converted into a configuration of the Project folder generation step (see below).
The existing project seeds based on the 0.x version of the seed will keep working, but again, I strongly recommend to regenerate them, as well as the corresponding branch folders. The old versions will keep working and this migration can be done incrementally.
The YAML configuration, either entered directly in the Jenkins configuration page or defined as a URI to a file, is no longer needed in version 1.x.
The table below explains how to convert the YAML elements into elements of the new Project folder generation step configuration.
| YAML element | Step configuration |
|---|---|
| project-class | Replace them by different seed jobs (1) |
| branch-strategy | Replaced by a direct configuration of the naming strategy in the seed job configuration |
| seed-expression | Project folder path + Project seed name |
| destructor-expression | Project folder path + Project destructor name |
| branch-seed-expression | Branch folder path + Branch seed name |
| branch-start-expression | Branch start name |
| branch-name-expression | Branch name |
| branch-name-prefixes | Ignored branch prefixes |
| branch-parameters | Extra branch parameters |
| branch-scm | Extra Branch SCM parameter |
| authorisations | Authorisations for the project |
| pipeline-commit | Event parameter which contains the commit |
| pipeline-delete | Delete complete pipeline on branch deletion |
| pipeline-auto | Regenerate pipeline when seed files changed |
| pipeline-trigger | Triggers the pipeline start when commit received |
| project-destructor | Project branch destructor |
| YAML element | Step configuration |
|---|---|
| auto-configure | Not supported any longer |
| projects | Direct configuration of projects is no longer supported (1) |
| commit-parameter | Not used any longer - see Event parameter which contains the commit |
| pipeline-start-auto | Not supported any longer - the decision to start a job or not at pipeline generation time belongs to the pipeline script or library, where a better control is possible, using typically the queue method |
| pipeline-generator-property-path | The seed plug-in will always look into seed/seed.properties and seed/seed.groovy - this is no longer configurable |
(1) any specific project configuration should be part either of its pipeline definition (at branch level) or introduced manually later on. The whole point of having the seed plugin in the first place is to industrialize the creation of projects based of common criteria. If you need several categories of projects, you create several categories of seed jobs, the same way you were using classes before.
The paths to the hooks have changed:
| Type | 0.x | 1.x |
|---|---|---|
| GitHub | seed-github/ | seed-github-api/ |
| BitBucket | seed-bitbucket/ | seed-bitbucket-api/ |
| HTTP | seed-http/ | seed-http-api/ |
The 0.x end points keep working, until version 2.x, but must be replaced for the projects having been migrated to 1.x.
In order to enable an end point for a project, configure the seed to use a connector name into the Type of trigger authorised configuration parameter:
-
noneor blank - no end point -
github- GitHub trigger authorised -
bitbucket- BitBucket trigger authorised -
http- HTTP trigger authorised
Hint: you can use a choice parameter in the Seed job and then pass the selection to the Type of trigger authorised parameter of the Project folder generation step.
The secret token is configured through the Secret token for trigger authorisation configuration parameter of the Project folder generation step.
- automatic start of pipelines upon (re)generation is now disabled and not configurable any longer. The DSL script or pipeline library must trigger the start of the pipeline explicitely, using the
queuemethod (see Generation). - the URI of the end points have evolved, to allow both v0 and v1 versions in a backward compatible mode (see above, Migration of web hooks)