Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Julien Greffe
    @jgreffe
    Hello @timja, thanks for your feedback,
    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"/>
    Tim Jacomb
    @timja
    yes correct @jgreffe
    it's a bug / limitation in maven-hpi-plugin, but use src/main/webapp for now unless you have time to fix the bug
    Julien Greffe
    @jgreffe

    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!!

    Julien Greffe
    @jgreffe
    After re-work, this seems to work:
    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/webapp content 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>
    Tim Jacomb
    @timja
    you should not have to do that
        <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>
    looks dodgy
    i.e. because you've changed from the src dir you now need to add maven-resources-plugin config so that any src files work
    aren't you overriding the plugin pom config by setting the warSourceDirectory as well? generally we set plugin pom properties and don't override the hpi-plugin config directly
    Julien Greffe
    @jgreffe

    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>
    Tim Jacomb
    @timja
    you can gitignore any libraries so there's no git changes
    probably good to capture this discussion on an issue in the maven-hpi-plugin repo I think
    sounds like your approach will work fine but this should work out of the box so should get some input to see if we change that value or just recommend everyone place in src/main/webapp
    Julien Greffe
    @jgreffe
    This case could be problematic if we stick to src/main/webapp when we want to manually copy external resources:
    • src/main/webapp contains JS with source control
    • other JS are manually copied from node_modules or any other directory to src/main/webapp > we would have to add some really specific patterns in .gitignore (?)
    Tim Jacomb
    @timja
    be explicit? or add a folder just for the lib?
    Julien Greffe
    @jgreffe
    Tim Jacomb
    @timja
    @jgreffe you shouldn't need all that frontend-maven-plugin config
    it's all in the parent pom and activated by a marker file
    apart from that seems fine although an upstream fix would be better :)

    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"

    Julien Greffe
    @jgreffe
    Thanks for all your suggestions @timja ! :heart_eyes:
    Pushed again, should be better now :)
    Agree about upstream fix, but I'll focus on making full cycle work within pipeline-stage-view for now.
    Thanks!
    Tim Jacomb
    @timja
    looking great, other suggestion I would have is to enable renovate for JS deps.
    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
    halkeye
    @halkeye:g4v.dev
    [m]
    did renovate get approved?
    Alexander Brandes
    @NotMyFault
    Renovate isn't installed on the org, but on selected repositories with npm or yarn I requested it on, to make dependency updates more maintainable
    You'll need to request and installation if you want to use it :eyes:
    Zbynek Konecny
    @zbynek
    what was the reason for moving away from dependabot? Grouping of dependencies?
    4 replies
    Mark Waite
    @MarkEWaite
    That was at least part of it. Renovate handles groups of dependencies better than dependabot.
    Alexander Brandes
    @NotMyFault

    what was the reason for moving away from dependabot? Grouping of dependencies?

    Yeah, that was the main reason. It can't create dependencies from mono repos, like babel/cli, babel/core, etc. and creates one for each dependency I had to update by hand in the past

    Although, dependabot doesn't support yarn 2, means we can't use it for jenkinsci/jenkins at all to keep up js dependencies.
    Daniel Beck
    @daniel-beck
    This message was deleted

    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)?

    Daniel Beck
    @daniel-beck
    (The latter is based on the assumption that user feedback is an important component to success y/n)
    Daniel Beck
    @daniel-beck
    What do I need to do to build Jenkins ~2.321? I always get "Unknown Syntax Error: Unsupported option name ("--mutex")." from yarn when building the :jenkins-war.
    halkeye
    @halkeye:g4v.dev
    [m]
    @daniel-beck: i don't know specifically, but for debugging purposes, what does yarn --version give you?
    Daniel Beck
    @daniel-beck
    $ yarn --version
    1.22.10
    halkeye
    @halkeye:g4v.dev
    [m]
    oh i guess the maven front end script deploys yarn somewhere else, like node sub directory or something?
    Daniel Beck
    @daniel-beck
    [INFO] --- frontend-maven-plugin:1.12.0:install-node-and-yarn (install node and yarn) @ jenkins-war ---
    [INFO] Node v14.16.0 is already installed.
    [INFO] Yarn 3.2.2 was installed, but we need version v1.22.10
    [INFO] Installing Yarn version v1.22.10
    I guess I'm patching the pom.xml to remove this argument
    halkeye
    @halkeye:g4v.dev
    [m]
    i'm guessing its not using yarn 1.22, cause it seems like --mutex is a yarn 1 thing
    Daniel Beck
    @daniel-beck
    Perhaps mvn clean doesn't clean enough and there's stuff still around from current versions of Jenkins?
    Daniel Beck
    @daniel-beck
    it worked when patching the pom.xml, good enough for a bit of bisecting
    UX SIG feedback welcome: jenkinsci/jenkins#6986 (unrelated to previous messages)
    Tim Jacomb
    @timja
    from watching the video it seems a bit jumpy but i'll try run it locally myself later on to get a better feel for it
    Daniel Beck
    @daniel-beck
    right, I'm not even sure background is what we want. Might be a border, border-left, or something else entirely. I just think there should be some indicator for what is newly added.
    (but animation that fades to "same as everything else" seems preferable to having a fixed last-child style, that's weird in logs without new content for a while.)
    Jan Faracik
    @janfaracik

    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?

    Hey,

    Defining success is tricky, e.g. I can't say for a fact that users are interacting with the larger search bar more than they were. I largely view something as successful based off of the feedback from UX SIG, PRs, fellow users and comments (e.g. YouTube).

    For the screens we want to look at going forward (e.g. the project/build pages) it'd be super helpful to define a set of criteria that we can assess any changes against + some useful stats about the existing implementation. This provides us some good ground as to why we're making the change and a set of criteria to say if the changes we've made were successful, which will be helpful if we face any backlash for changing a design that's been around for over a decade (even if it has flaws).

    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)?

    An unobtrusive way to gather feedback in core would be great. I'm not sure what the best way to approach something like that would be as it'd have to be somewhat visible but without getting in the way of the user, nobody wants the classic Windows esque feedback popups. A 'feedback' link in the footer might be helpful.

    Hrushikesh
    @Hrushi20

    Hello World, I wanted to create a table to display git maintenance logs in UI. I planned on using the DataTable Plugin in Jenkins. While using that plugin, I am getting an import error which states that html,css & js files are not found.

    The error is caused by this line <st:adjunct includes="io.jenkins.plugins.data-tables"/>. I am currently using jenkins version 2.332.4