Hello,
currently I’m test-running 2.319.1 (coming 2.303.3) on a trial system.
I have/had an administrative monitor for it, telling (full text below) that master will be renamed to "built-in node’.
I’m slightly confused about several aspects: (Numbered for easier reference)
It seems the label I get back, via “{JENKINS_URL}/computer/api/xml?xpath=*/computer/displayName&wrapper=foo” is “Built-In Node”
This is unfortunate, because it is two words. It made our - maybe naive - way of processing this fail and is generally harder to handle in shell, than a singe word.
Also, the label for it is “built-in” (without the “node”). Is there a reason for these two different names ?
(I guess it is too late to ask, to have this unified to use of “Built-In” ? (Or maybe even “builtIn”") …)
Sorry, I know there had been a discussion, but I had been too busy with day-to-day tasks…
Does this name “controller” show up somewhere in the interfaces ? (So far did not see it)
If I acknowledge the administrative monitor, what will this actually do ?
(I have the configuration files checked in to a GIT repo. The only difference I found is:
Monitor text:
"The word “master” is being retired as the term for the main Jenkins process and the built-in node. The main process is now called “controller” and the built-in node is called just “built-in node”. The UI has been updated with these changes. The following features are also affected:
The implicit label of the built-in node changes from master to built-in .
The built-in node’s NODE_NAME environment variable also changes from master to built-in .
These changes could affect build behavior, so are not applied automatically. Before you apply these changes, you should do the following:
Review label assignments in job configurations and tool installers for uses of master label. Any such label assignments will not match the built-in node after migration. Besides updating these assignments, you could also explicitly add the master label to the built-in node.
Review use of the NODE_NAME environment variable in build scripts."
as a non core developer I can’t really speak to that, but there was a discussion in April, and thus the changes have been shipped for more than 6 months now, so I’m not sure how much room there is for changes.
Since you queried for the display name and not the label, I would expect and accept spaces in the name. Display names are intended to be human readable and may contain spaces. Labels are best without spaces.
The label on that agent previously was the same as the display name. The label on that agent is now ‘built-in’ and is different from the display name.
The label on the node is ‘built-in’. It does not include any spaces in the label. It is best to not run jobs on the controller. It is a security risk. See the controller isolation page for more details.
The word controller is used in online help, messages, and more.
The behavior inside the code is described in the 2.319.1 upgrade guide. When the migration is applied, the node that was previously automatically labeled ‘controller’ is now automatically labeled ‘built-in’.
If you prefer to see a live discussion of the change, you can watch the recording of Darin Pope’s livestream of the changes in 2.319.1.
Hello,
ok, I understood my problem 1 now better. I’ve been using “…xpath=*/computer/displayName” to get a list of machines, connected to my CI.
I then used these to e.g. check or update stuff on these machines.
So what I “really” need is a way to get a list of machine names.
“displayName” seemed to do the trick (despite I had to “translate” master to the physical node name.)
The labels won’t do the trick, because obviously more than one machine, can (and often will) have the same label attached.
I’ll go hunting for a better way to get this info (“List me all machine names, this CI consists of”).
All hints welcome.
If you are using Bourne shell or a derivative make sure you allow the shell to accept spaces.
For example this command:
curl -sSf http://httpbin.org/status/403 2>&1 | while read ERR; do printf ">>%s<<\n" "${ERR}"; done
Should produce
>>curl: (22) The requested URL returned error: 403<<
This way the ERR variable contains string with spaces. Make sure you always use "${ERR}" as a parameter to other commands and it will be passed correctly.
