Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Ensure applying configuration as code retains the offline cause of agents#26749

Merged
timja merged 1 commit into
jenkinsci:masterfrom
mawinter69:offline-cause-casc
May 7, 2026
Merged

Ensure applying configuration as code retains the offline cause of agents#26749
timja merged 1 commit into
jenkinsci:masterfrom
mawinter69:offline-cause-casc

Conversation

@mawinter69
Copy link
Copy Markdown
Contributor

@mawinter69 mawinter69 commented May 5, 2026 •
edited by MarkEWaite
Loading

When configuring agents with configuration as code the offline cause is not maintained in the yaml. So the offline cause is lost when reapplying casc or restarting Jenkins.

This change retains the offline cause in those cases.

Fixes #26750

Testing done

  • Install configuration as code plugin
  • create one agent and connect it
  • export the casc and only keep the jenkins -> nodes in the yaml
  • apply casc
  • take agent offline
  • apply casc -> agent is still offline

Added a unit test that fails without and succeeds with this change

Screenshots (UI changes only)

Before

After

Proposed changelog entries

  • Ensure applying configuration as code retains the offline cause of agent (regression in 2.482).

Proposed changelog category

/label bug,regression-fix

Proposed upgrade guidelines

N/A

Submitter checklist

  • The issue, if it exists, is well-described.
  • The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see examples). Fill in the Proposed upgrade guidelines section only if there are breaking changes or changes that may require extra steps from users during upgrade.
  • There is automated testing or an explanation as to why this change has no tests.
  • New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate.
  • New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO"), if applicable.
  • UI changes do not introduce regressions when enforcing the current default rules of Content Security Policy Plugin. In particular, new or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content Security Policy (CSP) directives (see documentation).
  • For dependency updates, there are links to external changelogs and, if possible, full differentials.
  • For new APIs and extension points, there is a link to at least one consumer.

Desired reviewers

@mention

Before the changes are marked as ready-for-merge:

Maintainer checklist

  • There are at least two (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 is not blocking the change.
  • Changelog entries in the pull request 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, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
  • If it would make sense to backport the change to LTS, be a Bug or Improvement, and either the issue or pull request must be labeled as lts-candidate to be considered.

@mawinter69
Ensure setNodes retains the offline cause
3ad78f9 
When configuring agents with configuration as code the offline cause is
not maintained in the yaml. So the offline cause is lost when reapplying
casc or restarting Jenkins.

This change retains the offline cause in those cases.
@comment-ops-bot comment-ops-bot Bot added the bug For changelog: Minor bug. Will be listed after features label May 5, 2026
@mawinter69 mawinter69 mentioned this pull request May 5, 2026
Closed
@mawinter69
Copy link
Copy Markdown
Contributor Author

mawinter69 commented May 5, 2026

Technically this is a change in behaviour. Maybe some users assume that after a restart of Jenkins all agents (configured with casc) that have been taken offline temporarily are back online.

@hjhafner
Copy link
Copy Markdown

hjhafner commented May 6, 2026

Technically this is a change in behaviour. Maybe some users assume that after a restart of Jenkins all agents (configured with casc) that have been taken offline temporarily are back online.

However, there are also users (like me) who expect agents that have been temporarily taken offline to remain offline even after a restart.

timja
timja approved these changes May 6, 2026
View reviewed changes
Copy link
Copy Markdown
Member

@timja timja left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@timja timja requested a review from a team May 6, 2026 06:41
@novinxy
Copy link
Copy Markdown

novinxy commented May 6, 2026

Technically this is a change in behaviour. Maybe some users assume that after a restart of Jenkins all agents (configured with casc) that have been taken offline temporarily are back online.

However, there are also users (like me) who expect agents that have been temporarily taken offline to remain offline even after a restart.

I just wanted to add more about expected behavior in my org :)
I think more common expected behavior is to remain offline.
I'm not sure about other use cases, but we use offline state to tinker/maintain agents.
Many times we faced issues that someone was maintaining machines and someone else in the meantime pushed new config to Jenkins.
Another example of our case is "automatic offline". We maintain about 70 parament agents with physical hardware. Sometimes we have hardware issues, which we automatically detect with scripts then send mail and offline state with message describing the issue. In rare occasions we had 20+ agents off with different messages. Changing Jcasc or restarting Jenkins during that time was lot of manual labor.

@mawinter69
Copy link
Copy Markdown
Contributor Author

mawinter69 commented May 6, 2026

Sure we need this fix. Question is if we should have some kind of property that one can set to keep the old behaviour

@timja
Copy link
Copy Markdown
Member

timja commented May 6, 2026

Sure we need this fix. Question is if we should have some kind of property that one can set to keep the old behaviour

I don't see why people would want agents they marked as offline to come back up on a restart / reload.

I'd leave it for now.

MarkEWaite
MarkEWaite approved these changes May 6, 2026
View reviewed changes
Copy link
Copy Markdown
Contributor

@MarkEWaite MarkEWaite left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This fixes an issue that I recently encountered in my test environment. I needed an agent offline due to misconfiguration and then restarted the controller and was surprised that the agent was online again.

@MarkEWaite
Copy link
Copy Markdown
Contributor

MarkEWaite commented May 6, 2026

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process.

/label ready-for-merge

@comment-ops-bot comment-ops-bot Bot added the ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback label May 6, 2026
@novinxy
Copy link
Copy Markdown

novinxy commented May 6, 2026

@MarkEWaite @mawinter69 @timja
Do you think this change could come with 2.555.2 or 2.555.3 LTS ? Or is it to big for patch release?

@MarkEWaite
Copy link
Copy Markdown
Contributor

MarkEWaite commented May 6, 2026

@MarkEWaite @mawinter69 @timja Do you think this change could come with 2.555.2 or 2.555.3 LTS ? Or is it to big for patch release?

I don't expect it to arrive in 2.555.2. We generally wait for the fix to be included in a weekly release before we include it in an LTS. The 2.555.2 LTS will release next Wednesday and the earliest this could arrive in a weekly release is next Tuesday.

We can consider it as a backport candidate for 2.555.3. It helps the backport decision process if we know that this is a regression and the Jenkins release that first introduced the regression.

@MarkEWaite MarkEWaite added lts-candidate When fixed, this issue should be considered for backporting to the LTS line 2.555.2-rejected labels May 6, 2026
@mawinter69
Copy link
Copy Markdown
Contributor Author

mawinter69 commented May 6, 2026

I think the issue was introduced with #9855 that reworked the temp offline handling in Computer and Node. That was first shipped in LTS 2.492.1

@comment-ops-bot comment-ops-bot Bot added the regression-fix Pull request that fixes a regression in one of the previous Jenkins releases label May 6, 2026
@timja timja merged commit fea6278 into jenkinsci:master May 7, 2026
21 checks passed
krisstern pushed a commit to shalinisudarsan/jenkins that referenced this pull request May 17, 2026
@mawinter69 @krisstern
Ensure applying configuration as code retains the offline cause of ag…
b28f8ce 
…ents (jenkinsci#26749)

(cherry picked from commit fea6278)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@MarkEWaite MarkEWaite MarkEWaite approved these changes

@timja timja timja approved these changes

Assignees

No one assigned

Labels

2.555.2-rejected bug For changelog: Minor bug. Will be listed after features lts-candidate When fixed, this issue should be considered for backporting to the LTS line ready-for-merge The PR is ready to go, and it will be merged soon if there is no negative feedback regression-fix Pull request that fixes a regression in one of the previous Jenkins releases

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Offline nodes become online after config reload

5 participants

@mawinter69 @hjhafner @novinxy @timja @MarkEWaite