Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-45327] Pickle EnvActionImpl to prevent multiple instances from existing after resumption #539

Merged
merged 2 commits into from
May 26, 2022

Conversation

dwnusbaum
Copy link
Member

See JENKINS-45327.

Right now, if you use env in a Pipeline in a way that causes EnvActionImpl to be serialized into the program's state, then after resumption you end up with a distinct instance of EnvActionImpl that is unrelated to the action attached to the WorkflowRun, so the owner for the deserialized EnvActionImpl is null, and getProperty and setProperty throw NPEs.

This PR fixes the issue by pickling EnvActionImpl so that it can be rehydrated using the action attached to the WorkflowRun, which maintains the expected singleton semantics and prevents issues.

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

import org.kohsuke.accmod.Restricted;
import org.kohsuke.accmod.restrictions.DoNotUse;
import org.kohsuke.stapler.export.Exported;
import org.kohsuke.stapler.export.ExportedBean;

@ExportedBean
public class EnvActionImpl extends GroovyObjectSupport implements EnvironmentAction.IncludingOverrides, Serializable, RunAction2 {
Copy link
Member Author

Choose a reason for hiding this comment

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

This will cause Pipelines which already have a serialized instance of EnvActionImpl to fail, but those instances would have thrown an NPE anyway if they were used, so my thinking is that this should not affect a significant number of users. We could leave it in place if we want to be extra careful though.

Copy link
Member

Choose a reason for hiding this comment

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

I think removing Serializable makes sense here.

* Prevents multiple instances of {@link EnvActionImpl} from existing for a single Pipeline after a Jenkins restart
* in case {@code env} is serialized into the program.
*/
private static class EnvActionImplPickle extends Pickle {
Copy link
Member Author

Choose a reason for hiding this comment

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

This has no internal state, we just use it as a hook to return EnvActionImpl.forRun(owner.getExecutable()) during deserialization, completely discarding the serialized object.

@dwnusbaum dwnusbaum requested review from car-roll and jglick May 19, 2022 21:44
@jglick jglick added the bug label May 19, 2022
import org.kohsuke.accmod.Restricted;
import org.kohsuke.accmod.restrictions.DoNotUse;
import org.kohsuke.stapler.export.Exported;
import org.kohsuke.stapler.export.ExportedBean;

@ExportedBean
public class EnvActionImpl extends GroovyObjectSupport implements EnvironmentAction.IncludingOverrides, Serializable, RunAction2 {
Copy link
Member

Choose a reason for hiding this comment

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

I think removing Serializable makes sense here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants