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-48431 Support both lightweight checkout AND build parameters #772

Closed
wants to merge 6 commits into from

Conversation

tgatinea
Copy link

@tgatinea tgatinea commented Oct 14, 2019

JENKINS-48431 Support both lightweight checkout AND build parameters

To support both lightweight checkout AND build parameters, we need to:

  • recover the environment parameters of the build
  • evaluate the SCM structure according to the build environment parameters

This leads to implement a new method into scm-api-plugin:
public static SCMFileSystem of(@nonnull Run build, @nonnull SCM scm, @checkfornull SCMRevision rev)

And it leads to implement:
public SCMFileSystem build(@nonnull Run build, @nonnull SCM scm, @checkfornull SCMRevision rev)

This method recovers from the current build the environment parameters and evaluate the SCM structure with the environment parameters.

It also does a git fetch with the refspec if the refspec is set in SCM.

It also take into account the case of a gerrit trigger with:

  • SCM refspec set to $GERRIT_REFSPEC
  • SCM branch set to FETCH_HEAD

This is done between lines 360 to 369

Note that this modification is in relation with two other pull requests that concerns:

Note that this pull request will not work if the pull request for scm-api-plugin is not valdated

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. This is simply a reminder of what we are going to look for before merging your code. If a checkbox or line does not apply to this pull request, delete it. We prefer all checkboxes to be checked before a pull request is merged

  • I have read the CONTRIBUTING doc
  • I have referenced the Jira issue related to my changes in one or more commit messages
  • I have added tests that verify my changes
  • Unit tests pass locally with my changes
  • I have added documentation as necessary
  • No Javadoc warnings were introduced with my changes
  • No spotbugs warnings were introduced with my changes
  • I have interactively tested my changes
    => I have tested my changes though workflow-cps-plugin under hpi
  • Any dependent changes have been merged and published in upstream modules (like git-client-plugin)
    => This pull request depends closely to the scm-api-plugin

Types of changes

What types of changes does your code introduce? Put an x in the boxes that apply. Delete the items in the list that do not apply

  • Dependency or infrastructure update
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)

Further comments

If this is a relatively large or complex change, start the discussion by explaining why you chose the solution you did and what alternatives you considered.

@MarkEWaite MarkEWaite added the enhancement Improvement or new feature label Oct 19, 2019
@tgatinea
Copy link
Author

@MarkEWaite I'm familiar with delivering plugins that gets dependencies.
Do I need to wait the end of the pull request jenkinsci/scm-api-plugin#78 before having some feedback for the git-plugin code?
Thanks by advance

@MarkEWaite
Copy link
Contributor

MarkEWaite commented Oct 22, 2019

You don't need to wait until the end of pull request jenkinsci/scm-api-plugin#78 before receiving feedback on the git plugin code. A reviewer could provide feedback based on the combination of pull requests.

I have limited time for review of pull requests and many other pull requests that I consider higher priority than your request to support lightweight checkout and build parameters. I will not review your pull request for a long time.

Top themes that I've prioritized include:

  1. BuildData bloat fix - JENKINS-19022
  2. Build initiation improvements - notifyCommit and others - JENKINS-29603, JENKINS-50168, JENKINS-25048
  3. Submodule improvements
  4. Caching for better performance and reduced disc use
  5. Changelog improvements

Other maintainers may have different priorities and different objectives. You're certainly welcome to check with @rsandell and @fcojfernandez on their priorities.

@hkrpavan
Copy link

hkrpavan commented Nov 24, 2019

@tgatinea were you able to generate plugin with this change? Do you have a private .hpi file to share with? I too waiting for this bug fix.

I tried building these three plugins locally and generated plugins. They seems to be not working. Looks like git client is crashing inspite of downgrading it to desired version.

java.lang.NullPointerException
at jenkins.plugins.git.GitSCMFileSystem.lambda$new$0(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$2.invoke(GitSCMFileSystem.java:191)
at org.jenkinsci.plugins.gitclient.AbstractGitAPIImpl.withRepository(AbstractGitAPIImpl.java:29)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.withRepository(CliGitAPIImpl.java:78)
at jenkins.plugins.git.GitSCMFileSystem.invoke(GitSCMFileSystem.java:187)
at jenkins.plugins.git.GitSCMFileSystem.(GitSCMFileSystem.java:117)
at jenkins.plugins.git.GitSCMFileSystem$BuilderImpl.build(GitSCMFileSystem.java:369)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:197)
at jenkins.scm.api.SCMFileSystem.of(SCMFileSystem.java:173)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:113)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:67)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:299)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:429)
Finished: FAILURE

@tgatinea
Copy link
Author

@hkrpavan Were you able to recompile the 3 plugins :

  • scm-api-plugin should be version 2.6.4-SNAPSHOT and need to be installed on jenkins first

  • I patched git-plugin from version stable-3.x
    => But now last version is 4.0.0 and I cannot recompile anymore
    => I probably have to rework
    This plugin is to be installed after previous plugin

  • workflow-cps-plugin was coming from 2.74 and it is now at 2.77

When I'll have time I will move to the last versions and push my code

@hkrpavan
Copy link

hkrpavan commented Nov 27, 2019

@tgatinea , Thanks for the reply. I could able to build these plugins (git-plugin stable-3.x) with your patch and make it working. This works good with declarative pipelines. Now i bumped into https://issues.jenkins-ci.org/browse/JENKINS-56943, though a different problem altogether. This too is part of light weight checkout while pulling resource file after Jenkinsfile pull.

Something like below in jenkinsfile,

agent {
kubernetes {
yamlFile 'build/pipelines/resources/KubernetesPodPipeline.yaml'
}
}

Started by user
Rebuilds build #242
Obtained build/Jenkinsfile from git ssh://XYZ/XYZ
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] readTrusted
[Pipeline] End of Pipeline
hudson.plugins.git.GitException: Command "git fetch --tags --progress --prune -- origin +refs/heads/FETCH_HEAD:refs/remotes/origin/FETCH_HEAD" returned status code 128:
stdout:
stderr: fatal: Couldn't find remote ref refs/heads/FETCH_HEAD
fatal: the remote end hung up unexpectedly

@tgatinea
Copy link
Author

@hkrpavan I have found why git-plugin does not compile anymore.
In my patch, I have :
String refspec = environment.expand(config.getRefspec()).trim();
String head = headName;
if (refspec == null) { ...

The spotbugs "mvn spotbugs:gui" complain that refspec cannot be null because String.trim() cannot be with a String null.
But in fact it can be the case as config.getRefspec() can return null value.

Now, if I code something like:
String refspec = environment.expand(config.getRefspec());
if (refspec != null) {
refspec = refspec.trim();
}
String head = headName;
if (refspec == null) { ...

Then it compiles because "refspec = environment.expand(config.getRefspec())" can be null.

@hkrpavan
Copy link

hkrpavan commented Nov 30, 2019

@tgatinea Thank you, i could able to build git-plugin with your latest changes from top if master branch. Also, i could able to resolve my other issue by updating workflow-multibranch-plugin to point to your SCMFileSystem method. Now i could able to resolve Kubernetes resource file pull issue.

https://issues.jenkins-ci.org/browse/JENKINS-56943

@vpod
Copy link

vpod commented Dec 6, 2019

@hkrpavan : so, let's vote and contribute both changes :-)

@jetersen
Copy link
Member

I have expanded the changes to include GitSCMTelescope and GitSCMFileSystem and removed the duplication :)

@jetersen
Copy link
Member

jetersen commented May 25, 2020

@vpod @hkrpavan
I created jenkinsci/workflow-multibranch-plugin#98 to solve the readTrusted step 😅

@jetersen
Copy link
Member

FYI I just deployed all the bits to our production server 💪 and our job passed successfully. #898 (comment)

Copy link
Member

@fcojfernandez fcojfernandez left a comment

Choose a reason for hiding this comment

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

Hi @tgatinea ! thanks for the PR. First, you're overriding some default behaviours, so it'd be nice to have some unitary testing.

@MarkEWaite
Copy link
Contributor

Superseded by #898

@MarkEWaite MarkEWaite closed this Jun 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement or new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants