Terminology cleanup: Docs for built-in node migration

[daniel-beck]

Add redirect and docs page for the built-in node name and label migration, corresponds to jenkinsci/jenkins#5425.

Deliberately not linked from the menu as this is basically "ephemeral" documentation -- it won't have much value in a year or two. The entry point is the admin monitor in Jenkins.

[oleg-nenashev]

Looks good! Does it also worth a blogpost?

[jsoref]

The merged PR text includes screenshot here.

Here's a screenshot:

Personally, I have a list of questions about this cleanup which I've left via Slack. Happy to talk things over.

Fwiw, I had to change ~30 jobs (29 classic and one pipeline). And I have no idea if what I did will work (so far, the one pipeline is running fine on the master side of the transition).

I used /label/master/ to find them all and then changed them to reference master||built-in instead, and now I have to use /label/master%7C%7Cbuilt-in/ to see them, but I'm hoping that on the other side they'll still run.

I think it'd be helpful to suggest actual before & after for classic and pipeline (and probably matrix). Some of us have inherited systems that are >10 years old where no one remembers how things work (many of these jobs haven't been intentionally run in that time).

[jsoref]

Oh, the most basic question is "How does one undo this?",

---

From a linguistic perspective:

-Jenkins to version 2.307 or newer
+Jenkins to version 2.307 and newer

[daniel-beck]

via Slack

Could you provide a link?

Oh, the most basic question is "How does one undo this?"

Seemed unnecessary, given the workaround which is essentially the same for the vast majority of use cases (label expressions). Could you explain why reverting is useful but the provided workaround is not?

[jsoref]

Could you provide a link?

https://kubernetes.slack.com/archives/C09R5RQNL/p1629937472001100

Could you explain why reverting is useful but the provided workaround is not?

Frankly, I have no idea. It's just that I don't know what it's actually doing, and it seems like it'd be easier to have a button to go both ways than to force me (if things are already burning) to try to do something else.

Keep in mind that I really don't know what might explode, but it sounds scary, and it seems like it'd be a pretty easy thing for Jenkins to be able to do, click to migrate and click to roll-back are much easier for peace-of-mind than "click to jump off a cliff" + "follow amorphous steps to half undo in a way that might fix your fires".

[daniel-beck]

I thought you were referring to the CDF Slack and was surprised when I didn't find anything.

I'm not signing up for yet another third party service to receive feedback, sorry.

[jsoref]

Sorry. I'll put it into the right slack. I miss irc.

[daniel-beck]

the right slack

I'm not sure the CDF Slack is much better, but it's the only one I could think of -- mostly used for CDF/LF interactions and such.

I miss irc.

We still have that, just on libera.chat: https://www.jenkins.io/chat/

And in case you haven't followed recent developments, there's also https://community.jenkins.io/

[jsoref]

I haven't followed. And the last think I need is another discourse.