I was trying to upgrade handlebars to latest 4.x version using current bundling @jenkins-cd/js-* in order to have minimal changes, but seems like a tricky process :/
What's strange is https://github.com/jenkinsci/js-samples/tree/master/step-06-handlebars-templates is working out-of-the-box (using @jenkins-cd/js-modules & @jenkins-cd/js-builder) :/
Thanks for your help/suggestions!
@jgreffe: https://github.com/jenkinsci/lighthouse-report-plugin/blob/master/package.json#L8
Parcel is dead easy
Hi !
In my organization, we use Jenkins+BlueOcean.
I would like to switch to https://github.com/jenkinsci/pipeline-graph-view-plugin (which is faster, lighter... and enough for our needs), but the README says "Disclaimer: this is currently an alpha..."
Is it still the case ? What's your recommendation about that ?
I tried creating a handlebars4-api-plugin locally, and then use it as adjunct in pipeline-stage-view-plugin.
When I run
mvn hpi:run on pipeline-stage-view-plugin, it seems the adjunct is resolved, but the JS itself is not: HTTP 404.But when I look at the content of locally mvn installed handlebars4 HPI, I get proper
/js/handlebars.js. What am I doing wrong?
hpi:run
src/main/webapp for hpi:run to work
code is local only, I didn't push yet :/
Anyway, right, seems putting some resources directly in
src/main/webapp of new handlebars4-api works. Is it because of the plugin pipeline-stage-view starting with hpi:run and using handlebars4-api has work/plugins/handlebars4-api.jpl containing Resource-Path: /Users/jgreffe/Workspaces/pulsar/handlebars4-api-plugin/src/main/webapp ?But I still don't get why in pipeline-stage-view I can directly reference a static resource from
bootstrap5-api even if it's not part of src/main/webapp(is it because it's a non SNAPSHOT version?) ?<script type="text/javascript" src="${resURL}/plugin/bootstrap5-api/js/bootstrap.js"/>I've updated my local pom to use the specific directory:
<plugin>
<groupId>org.jenkins-ci.tools</groupId>
<artifactId>maven-hpi-plugin</artifactId>
<version>${hpi-plugin.version}</version>
<configuration>
<warSourceDirectory>${project.build.directory}/${project.artifactId}</warSourceDirectory>
</configuration>
</plugin>https://jenkinsci.github.io/maven-hpi-plugin/hpi-mojo.html#warSourceDirectory
Seems to work!
Thanks!!
we use
${project.build.directory}/webapp as the "temporary" directory containing all webapp resources:- proper declaration of
Resource-Path: /Users/jgreffe/Workspaces/pulsar/handlebars4-api-plugin/target/webapp - proper copy of
/Users/jgreffe/Workspaces/pulsar/handlebars4-api-plugin/target/webappcontent in root of generated HPI
<plugin>
<groupId>org.jenkins-ci.tools</groupId>
<artifactId>maven-hpi-plugin</artifactId>
<version>${hpi-plugin.version}</version>
<configuration>
<warSourceDirectory>${project.build.directory}/webapp</warSourceDirectory>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-webapp-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/webapp</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/src/main/webapp</directory>
</resource>
</resources>
</configuration>
</execution>
<execution>
<id>copy-node-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/webapp/js</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/node_modules/...</directory>
</resource>
</resources>
</configuration>
</execution>
</executions>
</plugin> <executions>
<execution>
<id>copy-webapp-resources</id>
<phase>process-resources</phase>
<goals>
<goal>copy-resources</goal>
</goals>
<configuration>
<outputDirectory>${project.build.directory}/webapp</outputDirectory>
<resources>
<resource>
<directory>${project.basedir}/src/main/webapp</directory>
</resource>
</resources>
</configuration>
</execution>warSourceDirectory as well? generally we set plugin pom properties and don't override the hpi-plugin config directly
Idea was to avoid putting things from node_modules directly in src/main/webapp which would involve git changes if module version changes.
As src/main/webapp is hard-coded in maven-hpi-plugin, I tried overriding argument warSourceDirectory.
With mvn help:effective-pom, I see the parent pom maven-hpi-plugin configuration is still used:
<plugin>
<groupId>org.jenkins-ci.tools</groupId>
<artifactId>maven-hpi-plugin</artifactId>
<version>3.32</version>
<extensions>true</extensions>
...
<configuration>
<warSourceDirectory>/Users/jgreffe/Workspaces/pulsar/handlebars4-api-plugin/target/webapp</warSourceDirectory>
<showDeprecation>true</showDeprecation>
<webApp>
<contextPath>/jenkins</contextPath>
</webApp>
<systemProperties>
<hudson.Main.development>true</hudson.Main.development>
</systemProperties>
</configuration>
</plugin>src/main/webapp when we want to manually copy external resources:src/main/webappcontains JS with source control- other JS are manually copied from
node_modulesor any other directory tosrc/main/webapp> we would have to add some really specific patterns in.gitignore(?)
and i'd suggest using CD rather than semantic versioning:
https://www.jenkins.io/doc/developer/publishing/releasing-cd/
There's a special format for API plugins, see "Versioning with wrapped components"
e.g. your npm version is out of date and renovate can update the pom.xml file for it:
https://github.com/jenkinsci/dark-theme-plugin/blob/master/renovate.json
4 replies
This has been intentional to make it simpler to test ideas that may or may not work - if they don’t work they have limited impact and can be iterated on quickly (such as the all caps table design, or the plugin manager search bar).
@janfaracik (triggered by Tim's new comment on your sidepanel PR):
What does success look like for these ideas/experiments? By when do you expect to be able to determine whether it was successful or not?
Does core need a built-in dedicated feedback feature to allow people to provide low barrier feedback on UI experiments (and to mark experiments as such)?
yarn --version give you?