jenkins
jenkins copied to clipboard
Allow formatted markup for node descriptions
See JENKINS-XXXXX.
Proposed changelog entries
- Allow HTML syntax for node descriptions.
Before
After
Proposed upgrade guidelines
No
Submitter checklist
- [ ] (If applicable) Jira issue is well described
- [x] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
- Fill-in the
Proposed changelog entries
section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
- Fill-in the
- [x] Appropriate autotests or explanation to why this change has no tests There are no changes in java code.
- [x] New public classes, fields, and methods are annotated with
@Restricted
or have@since TODO
Javadoc, as appropriate. There are no changes in java code. - [x] For dependency updates: links to external changelogs and, if possible, full diffs There are no changes in java code.
Desired reviewers
@mention
Maintainer checklist
Before the changes are marked as ready-for-merge
:
- [ ] There are at least 2 approvals for the pull request and no outstanding requests for change
- [ ] Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
- [ ] Changelog entries in the PR title and/or
Proposed changelog entries
are accurate, human-readable, and in the imperative mood - [ ] Proper changelog labels are set so that the changelog can be generated automatically
- [ ] If the change needs additional upgrade steps from users,
upgrade-guide-needed
label is set and there is aProposed upgrade guidelines
section in the PR title. (example) - [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as
lts-candidate
to be considered (see query).
I try to find some example. There is editableDescrption page but it does not work on this page. Because this page has an extra config page. Has you some idea?
I try to find some example. There is editableDescrption page but it does not work on this page. Because this page has an extra config page. Has you some idea?
Changing the input from a textbox to a textarea in hudson.slaves.DumbSlave.configure-entries.jelly pointing the markup formatter to codemirror does generate named box. Existing spots are for example hudson.model.Job.configure.jelly utilizing this feature.
So editable config description works too.
-->
The button to 'swicht temporally offline' is moved too. So it has the same look like in configure job page. @NotMyFault thanks for hits.
How does this look in matrix-project? I think that renders node descriptions and should be adapted.
Did you check whether project history explains why nodes have plain text nodeDescription
but everything else has formatted description
?
How does this look in matrix-project? I think that renders node descriptions and should be adapted. No I have no idea, newer use it, but I will try it and get feedback here
Did you check whether project history explains why nodes have plain text
nodeDescription
but everything else has formatteddescription
?
Nope, I was just angry, because we can not use longer description. We want to fill the description dynamically to get some node specific info when is started / used. Ex:
- installed tools and their versions like git, java ...
- real platform name (the platform labeler plugin does not work as expected for us)
- IpConfig
- Reboot history, we need to reboot the nodes many times during our 'build' process ....
So we need bigger description field.
But I will try to find the reason. It was also terrible for me to fix it, because you true anywhere else it is description
matrix-project
So the matrix-project renders node labels. Node name and description are not changed.
I think my changes has no effect on this.
Did you check whether project history explains why nodes have plain text
nodeDescription
but everything else has formatteddescription
?
So I have try to find the reason, It looks that it was just "for ever". When you agree, I would create new Jira issue for that. So we can "fix" it little later. I prefer to set the 'nodeDescription' to obsolete, but this can not be decided by me.
I found one more usage of nodeDescription
I has also check whole jenkins core ws for nodeDescription and I think this was the last one.
@mPokornyETM Thanks! To clarify, I'm not opposed to this change per se, just wondering whether there's a good reason for the discrepancy in both field name and behavior. I expect we'll merge this or a variant in the end, solving your problem.
Re matrix-project, I was surprised by your answer and checked, and while
looks like there would be an agent description rendered there, there's no support for that -- everything is treated as a label, not as an agent name, internally: https://github.com/jenkinsci/matrix-project-plugin/blob/7aea491852f39b51379a2f6f2dd490f7d191441e/src/main/java/hudson/matrix/LabelAxis.java#L90-L99 Additionally, the label descriptions do not get the renderer applied, so it looks terrible with any non-default markup formatter. That's an issue with the plugin alone though.
@daniel-beck Ah sorry that was misunderstanding from my side. I think it renders some hove the /computer/<agentName>
page, but it is used here in the config page from the matrix-project self.
The solution is strange. From my side I prefer to remove the description from this page, because it is not necessary and it looks like the lol ()
is a function and not the node name (description)
Please allow me one question. What shall be done to finish this PR?
Please allow me one question. What shall be done to finish this PR?
At the moment, needs more reviews from others, and consequently some patience from you. If anything is missing from this PR, that'll be brought up in reviews.
Nit:
The description of the built-in node is defined by Hudson.NodeDescription
in hudson/model/Messages.properties
as
the Jenkins controller's built-in node
That looks weird with this change in presentation:
It should be upgraded to a full sentence since it's no longer a short phrase in parentheses (no HTML though, or any characters likely to lead to problem in any common(ish) markup language).
Please allow me one question. What shall be done to finish this PR?
At the moment, needs more reviews from others, and consequently some patience from you. If anything is missing from this PR, that'll be brought up in reviews.
thanks, I am patient enough, but I am excited, Like a small child
Nit:
The description of the built-in node is defined by
Hudson.NodeDescription
inhudson/model/Messages.properties
asthe Jenkins controller's built-in node
That looks weird with this change in presentation:
![]()
It should be upgraded to a full sentence since it's no longer a short phrase in parentheses (no HTML though, or any characters likely to lead to problem in any common(ish) markup language).
Hm I see. The same issue was in System Information
page. My quick and dirty solution was
<div style="margin-bottom: var(--section-padding);">
Do you now about some better class or html element, which will render the space correctly?
dirty fix for padding
It should be upgraded to a full sentence since it's no longer a short phrase in parentheses (no HTML though, or any characters likely to lead to problem in any common(ish) markup language).
Hm I see. The same issue was in
System Information
page. My quick and dirty solution was<div style="margin-bottom: var(--section-padding);">
To clarify, the comment you quoted was about the phrasing, not the presentation.
Thanks for taking care of the margin!
Hi @daniel-beck . Any news here?
This looks fine. We need to improve the code once the icon attributes is fixed (@janfaracik https://github.com/jenkinsci/jenkins/pull/6511/files#r879816769).
Once this is fixed, we can revisit the
<span class="icon-lg"/>
as the icon is notlg
anyway butmd
.
Happy to say the fix for the symbol attributes is merged in :) https://github.com/jenkinsci/jenkins/pull/6609
This looks fine. We need to improve the code once the icon attributes is fixed (@janfaracik https://github.com/jenkinsci/jenkins/pull/6511/files#r879816769). Once this is fixed, we can revisit the
<span class="icon-lg"/>
as the icon is notlg
anyway butmd
.Happy to say the fix for the symbol attributes is merged in :) #6609
I totally missed that. So please @mPokornyETM, you could please review your commit to leverage that fix?
Hi of cores I do that. Compiling ... waiting ... ;-) but this shall be not a big deal
before
after
maybe is my jenkins workspace not up to date, but your screen-shot looks good, so suggestion is approved. thx for contribution
Two remarks testing the latest build:
- The built-in node's description still looks weird now that it's on a standalone line.
- Inline editing of the description is not possible. Was this previously brought up and dismissed already? If not, is there a reason this wasn't added?
Two remarks testing the latest build:
- The built-in node's description still looks weird now that it's on a standalone line. Strange. I will check it.
- Inline editing of the description is not possible. Was this previously brought up and dismissed already? If not, is there a reason this wasn't added? This was also my first try, but there is extra configuration page, where you can edit the description. So I revert it. But I think it is low effort to allow both variants. Shall I implement it?
Strange. I will check it.
To clarify, it's the specific string from Messages.properties that e.g. starts with a lowercase letter. That made sense in parentheses, less so with the new presentation.
This was also my first try, but there is extra configuration page, where you can edit the description. So I revert it. But I think it is low effort to allow both variants. Shall I implement it?
I think that would be useful to have, especially as it would be consistent with every other "description" field in Jenkins (Views, Jobs, Builds, Users, all have inline description editing)
So the description in built-in node shall looks like before But the inline description does not work for me :-( I have added
<t:editableDescription permission="${it.CONFIGURE}" />
and after save I get following esception:
404 Not Found
Stapler processed this HTTP request as follows, but couldn't find the resource to consume the request
-> evaluate(<hudson.model.Hudson@1d0ce1eb> :hudson.model.Hudson,"/computer/firstAgent/submitDescription")
-> evaluate(((StaplerProxy)<hudson.model.Hudson@1d0ce1eb>).getTarget(),"/computer/firstAgent/submitDescription")
-> evaluate(<hudson.model.Hudson@1d0ce1eb>.getComputer(),"/firstAgent/submitDescription")
-> evaluate(<hudson.model.ComputerSet@59a6b974> :hudson.model.ComputerSet,"/firstAgent/submitDescription")
-> evaluate(<hudson.model.ComputerSet@59a6b974>.getDynamic("firstAgent",...),"/submitDescription")
-> evaluate(<hudson.slaves.SlaveComputer@6c08d0f3> :hudson.slaves.SlaveComputer,"/submitDescription")
-> evaluate(((StaplerProxy)<hudson.slaves.SlaveComputer@6c08d0f3>).getTarget(),"/submitDescription")
-> evaluate(<hudson.slaves.SlaveComputer@6c08d0f3>.getDynamic("submitDescription",...),"")
[email protected]("submitDescription",...)==null. Back tracking.
-> No matching rule was found on <hudson.slaves.SlaveComputer@6c08d0f3> for "/submitDescription"
Sorry I have no idea how to fix it. @daniel-beck has you some idea?
Yeah, that's because there's no #doSubmitDescription
method on the Computer
you're editing. You'll need to add that, and process the inline submission there.
So the description in built-in node shall looks like before
No, it looks good with the change. It's just the exact wording no longer works when it's a full standalone paragraph. Just replace
the Jenkins controller's built-in node
with
This is the Jenkins controller's built-in node.
or if you want to make it even nicer,
This is the Jenkins controller's built-in node. Builds running on this node will execute on the same system and as the same user as the Jenkins controller. This is appropriate e.g. for special jobs performing backups, but in general you should run builds on agents.
(Or something along those lines. What makes this slightly awkward is that you cannot know what the markup formatter is going to be, so no rich formatting. Additionally, no inline editing for this node, as the text is uneditable.)
Is https://github.com/daniel-beck/jenkins/commit/ae3e1c0ccaf1b7a07d4d3e039d3d22ff0b8e5456 something you could see as part of your PR? WDYT?
Now I remember why I gave up implementing this a few years ago. There's so much crap hardcoded in inline description editing. I'll give it a try…