Hi all, Just to provide an update on this topic, I have added support of Bill of Materials (in the current draft version) to Custom WAR Packager <https://github.com/jenkinsci/custom-war-packager> and used it in several automation flows. E.g. see Integration Testing for Artifact Manager S3 <https://github.com/jenkinsci/artifact-manager-s3-plugin/pull/20>. I can also rework Remoting (PR) <https://github.com/jenkinsci/remoting/pull/265> and Stapler (PR) <https://github.com/stapler/stapler/pull/138>flows to use BOM there if it is needed for a reference implementation.
Do I gravely need BOM in these pull requests? The answer is "No" as Jesse pointed out. Custom WAR packager uses its own YAML format <https://github.com/jenkinsci/custom-war-packager#configuration-file> which can be integrated into essentials.yml format created by Raul Arabaolaza <https://github.com/raul-arabaolaza> for integration tests. This format is generally more flexible for packaging WARs for testing purposes (build settings, relative FS paths, support of embedding System properties and Groovy scripts, etc.). In this PR <https://github.com/jenkinsci/custom-war-packager/pull/22> and JEP comments I have pointed out several weaknesses of the current BOM proposal: - The provided justification for BOM is true, but actually it is already achieved by Custom WAR Packager. - BOM does not make much difference there as described above - "We want to unify the description format across projects within Jenkins (e.g. Jenkins Essentials, Jenkins X, Docker Packaging, etc.)." is the real thing we should focus on IMHO, but it needs to be expanded (see proposals below) - BOM format is not specified. The JEP proposal just provides an example without specifying fields. It refers the K8s notation, but that's it. There is no link to K8s specification and the version, and this specification may drift over time. It leads to all my further comments here - "Metadata/labels" are not specified. What is a "must", what is "optional"? - E.g. what is field 'name' and how should it be used? - Purpose of "Metadata/annotations" section is not clear. - There is neither examples nor documentation - I would expect to be able to put any custom data there. E.g. for Custom WAR packager I would expect to put build and packaging settings there. OTOH for Jenkins Essentials I would expect this section to have some deployment rules and so - We had a private discussion with Carlos, and his explanation was that "annotations" in K8s notation is just a key-value mapping without object support. It does not allow passing complex configurations via them and hence does not allow using BOM as a sole input for test automation flows (like ATH which is used for justification) - "Core" section needs specification - I'd guess it defines version of WAR file, but it's not clear from documentation. Note that version of WAR and version of the bundled Jenkins Core may differ (timestamped releases, custom WAR builds, etc.) - "Core" does not define "artifactId" or "groupId". It means that only standard Jenkins WAR "org.jenkins-ci.main:jenkins-war" may be used. What if I want to define BOM for a custom product based on Jenkins? It is a real use-case for me - Vague "components" section. It is not clear what can be defined there and how it should be handled. - Is it only JARs? What about Jenkins Modules, Resources, System Groovy Scripts, etc. - There is no "type" field or whatever which would allow to distinguish it - Plugins and Components support only "version" and "ref" fields - In test automation flows we need to test unreleased components in repositories, and it would be really useful to just reference components by path to sources and by path to HPI/JAR like it's done in custom WAR packager - It is not clear how "environment" should be used. - Can we define multiple environments? Or just a single one? - Can environments override plugins/components? Or do they just append new ones? - "status" section requires all components/plugins to have artifactId/groupId/versions - What if I add a "Groovy init gook" script from a repository as a component? This component has no real version since it's not released separately. Am I expected to mock them somehow (e.g. commitId)? - Does BOM expect all listed components to be available in Maven repo? IMHO BOM specification should be created and documented properly, maybe using one of standard YAML specification languages. Even with the comments above, I think that the BOM is actually useful and should be finalized. Why? - We really need an inter-exchange format. As Jesse said somewhere, Maven POM/BOM is not a silver-bullet in this area since it does not allow passing extra metadata easily - Examples of inter-exchange: - Custom Packager generates a specification of bundled components which is then used by runPCT/runATH steps to define defaults for running steps (INFRA-1623 <https://issues.jenkins-ci.org/browse/INFRA-1623>) - WAR bundles ship BOMs internally so that tools like PCT can easily determine what's inside without parsing files - BOM can be used as a source for repackaging third-party WARs. E.g. somebody may be building a custom Docker image on the top of jenkins/blueocean, and BOM could help to resolve dependencies there. - Jenkins Essentials could be shipping BOM so that the same set of "Verified plugins" could be used by users who are not ready to switch to AWS but still want to get extra insurance about the plugin cross-compatibility So I am +1 regarding finalizing BOM as JEP. Bes regards, Oleg On Tuesday, May 1, 2018 at 3:17:44 PM UTC+2, Jesse Glick wrote: > > On Mon, Apr 30, 2018 at 4:47 PM, R. Tyler Croy <ty...@monkeypox.org > <javascript:>> wrote: > > If an update-incrementals tool existed, then yes, that would address my > > concerns here. > > OK, good to know I am not completely off base here. > > > I more wanted to make sure that we weren't going to have two > > or three implementations of what `update-incrementals` effectively > should be > > providing. > > There might be two or three scripts to deal with different syntaxes; > for example, it would be useful to have an equivalent to `mvn > versions:use-latest-releases` which grokked Incrementals and updated a > `pom.xml`. But yes they should share an underlying library of some > kind. > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/542d0afb-86bd-4f00-a714-96a2bec639b4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
