Why add this try-catch? It changes the user visible behavior.

I'd like to see all the other credential methods call this one.

For example:

    public GitHubBuilder withOAuthToken(String oauthToken, String user) {
        withCredentialProvider(ImmutableCredentialProvider.fromOauthToken(oauthToken));
        this.user = user;
        return this;
    }

That would let us remove the oauthToken and password instance fields from the class (and down the call chain).

@MarcosCela This is looking very good. Having token generation handled outside of the GitHub class is great.

I think that it's better to let users chose what kind of JWT libraries they use.

Are there a lot of different JWT token libraries?

If there is a specific and clear advantage to not generating the JWT token inside this library it is completely fine to leave that to the user. But as I understand it, the only reason users get JWT tokens is to immediately turn around and get GitHub App credential. If that is the case, why force them to think about it? With the way you've implemented it, looks like you could do both. Allow people to have control AND provide a default implementation in the extras package the people could use if they don't need that control.

@MarcosCela Adding dependencies - you could follow the pattern of putting an implementation of the CredentialsProvider in the extras package and make JWT an optional dependency. That would let users choose to use that provider, letting this project provide a tested stable implementation, while also not forcing people to take dependencies they don't need.

I'm not sure how to go about testing this - the behavior was (obviously) untested before this change.

JENKINS-48828

There was an error being throw when viewing the multibranch pipeline children of a Bitbucket Team job.

The error was being thrown from doFillRepositoryItems: https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/24d9487c9dcdc6e5f00f9c891b162da3bba3cb3c/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMSource.java#L1191-L1212

The equivalent method in github-branch-source is quite a bit different: https://github.com/jenkinsci/github-branch-source-plugin/blob/490693b59b83a4a82b0b94dd1ba2c7b5870be005/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java#L2161-L2180

This change makes the method here look like the method in github-branch-source.

Tested manually with and without this change and it appears to work.

Your checklist for this pull request

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or in Jenkins JIRA
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Did you provide a test-case? That demonstrates feature works or fixes the issue.

<!-- Put an x into the [ ] to show you have filled the information below Describe your pull request below -->

The latest branch-api honors quiet period. This means some test operations need to wait longer before checking.

Increment the Jackson version

Oh, what does this trait look like in the UI, can you give a screenshot?

If you only want this trait to control "Send Success notification for Unstable", that name should specifically say that.

Otherwise, it should be more generic to allow for additional values later.

Similarly, if you only plan to have one value having it be part of the constructor is fine. If you think there might be additional values later, making the constructor empty and using a setter would be better.

    public BitbucketBuildStatusNotificationsTrait() {

     * @return {@code true} if notifications should be disabled.

The name should make it clear that it is setting the notification sent, not changing the actual result of the run. I'm not sure of the best way to say it.

    private boolean notifyUnstableBuildAsSuccessful;

Or

    private boolean notifySuccessfulForUnstableBuild;

Or

    private boolean sendSuccessNotificationForUnstableBuild

    @Symbol("bitbucketNotifications")

     * Returns {@code true} if notifications should be disabled.

This should probably be at the top of the method. None of these should run on non-bitbucket sources, right?

jackson-datatype-json-org is used by pipeline-model-definition-plugin among others.

Description

Before GitHub App Credentials, cache folders not being cleaned up was okay. It was sometimes even an advantage since cached values that were extremely stable didn't have to be reloaded even across connection instances. However, with GitHub App Credentials the password (token) is regenerated on a regular basis, resulting in new connections with new caches.

This change cleans up cache folders when GitHub App connections are no longer used. Behavior for non-GitHubAppCredential connections is unchanged to preserve the advantages of the existing behavior for standard credentials.

See JENKINS-63711 for further information.

Submitter checklist

• [x] Link to JIRA ticket in description, if appropriate.
• [x] Change is code complete and matches issue description
• [ ] Automated tests have been added to exercise the changes
• [ ] Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• [ ] Run the changes and verify that the change matches the issue description
• [ ] Reviewed the code
• [ ] Verified that the appropriate tests have been written or valid explanation given

Documentation changes

• [ ] Link to jenkins.io PR, or an explanation for why no doc changes are needed

Users/aliases to notify

Description

See JENKINS-63698.

Submitter checklist

• [x] Link to JIRA ticket in description, if appropriate.
• [x] Change is code complete and matches issue description
• [ ] Appropriate unit or acceptance tests or explanation to why this change has no tests
• [ ] Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• [ ] Run the changes and verified the change matches the issue description
• [ ] Reviewed the code
• [ ] Verified that the appropriate tests have been written or valid explanation given

Use-case

In HubSpot we use the github-api and are very happy with the implementation. To reduce the load the to requests sent to GitHub and GitHub:Enterprise contents API we would like to use the ETag to store contents of files in a persistent key-value store where the key is contains the ETag and the value is the contents of the file. This is meant to be an implementation that extends beyond the standard 60 seconds HTTP cache provided by OkHttp.

So, when we want to get the contents of a file we will add the ETag to the Request headers. In the response, if the ETag matches, we will get a 304 and empty file contents. If not - we will get the response as usual.

Request

Would it be possible to somehow expose ETag when getting file contents. Perhaps even in the GHContent object itself? Or maybe have a method dedicated to returning a completely new object that contains both the current GHContent, the status code and a field for the ETag? With that said, would it also be possible to have an ETag parameter be added to a method so that the ETag can be included in Request headers?

@AlexShtarbev I'm going to close this for now, you are welcome to reopen if needed.

@seregamorph Did see this? https://github.com/hub4j/github-api/pull/944/files#r494672997 You can change it, we can discuss further in the PR, or you can split that part of the change into another PR and we can continue discussion there. Up to you. Thanks for contributing!

Thanks @cliffmeyers @eplodn @jglick . I'll merge this change and add a task to tombstone this plugin.

Description

See JENKINS-63698.

Submitter checklist

• [x] Link to JIRA ticket in description, if appropriate.
• [x] Change is code complete and matches issue description
• [ ] Appropriate unit or acceptance tests or explanation to why this change has no tests
• [ ] Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• [ ] Run the changes and verified the change matches the issue description
• [ ] Reviewed the code
• [ ] Verified that the appropriate tests have been written or valid explanation given

I would also suggest moving all these into GitHubBuilder and have a method GitHubBuilder.withCredentialProvider(CredentialProvider) which can be internal for now. Then this constructor just sets this.credentialProvider = credentialProvider pass from the builder.

                this.credentialProvider = ImmutableCredentialProvider.ANONYMOUS;

this.credentialProvider = ImmutableCredentialProvider.fromLoginAndPassword(login, password);

            this.credentialProvider = ImmutableCredentialProvider.fromOAuthToken(String.format("token %s", oauthAccessToken));

Description

Webhook event GHPullRequestReviewEvent: pull_request_review has review object in it which declares html_url field:

{
  "action": "submitted",
  "review": {
    "id": 496232606,
    "node_id": "MDE3OlB1bGxSZXF1ZXN0UmV2aWV3NDk2MjMyNjA2",
    "user": {
      "login": "schernov-xo",
      "id": 41187778,
      "node_id": "MDQ6VXNlcjQxMTg3Nzc4",
      "avatar_url": "https://avatars3.githubusercontent.com/u/41187778?v=4",
      "gravatar_id": "",
      "url": "https://api.github.com/users/schernov-xo",
      "html_url": "https://github.com/schernov-xo",
      "followers_url": "https://api.github.com/users/schernov-xo/followers",
      "following_url": "https://api.github.com/users/schernov-xo/following{/other_user}",
      "gists_url": "https://api.github.com/users/schernov-xo/gists{/gist_id}",
      "starred_url": "https://api.github.com/users/schernov-xo/starred{/owner}{/repo}",
      "subscriptions_url": "https://api.github.com/users/schernov-xo/subscriptions",
      "organizations_url": "https://api.github.com/users/schernov-xo/orgs",
      "repos_url": "https://api.github.com/users/schernov-xo/repos",
      "events_url": "https://api.github.com/users/schernov-xo/events{/privacy}",
      "received_events_url": "https://api.github.com/users/schernov-xo/received_events",
      "type": "User",
      "site_admin": false
    },
    "body": "",
    "commit_id": "c3acd4733a645e1c6ae3b6da83068ae12099f616",
    "submitted_at": "2020-09-25T09:52:57Z",
    "state": "commented",
    "html_url": "https://github.com/trilogy-group/northplains-telescope-api/pull/21#pullrequestreview-496232606",
    "pull_request_url": "https://api.github.com/repos/trilogy-group/northplains-telescope-api/pulls/21",
...

Old implementation ignores it (always null).

Proof: see the test, event existing test payload pull_request_review.json has it (ignored in test).

Before submitting a PR:

We love getting PRs, but we hate asking people for the same basic changes every time.

• [ ] Push your changes to a branch other than master. Create your PR from that branch.
• [ ] Add JavaDocs and other comments
• [ ] Write tests that run and pass in CI. See CONTRIBUTING.md for details on how to capture snapshot data.
• [ ] Run mvn clean compile locally. This may reformat your code, commit those changes.
• [ ] Run mvn -D enable-ci clean install site locally. If this command doesn't succeed, your change will not pass CI.

When creating a PR:

• [ ] Fill in the "Description" above.
• [ ] Enable "Allow edits from maintainers".

@seregamorph "standardize to java naming" - agreed. It just hasn't been a priority. Especially since we don't have sufficient code coverage to have high confidence in tests ensuring it is done right. PR welcome.

Increment the Jackson version

JENKINS-48828

There was an error being throw when viewing the multibranch pipeline children of a Bitbucket Team job.

The error was being thrown from doFillRepositoryItems: https://github.com/jenkinsci/bitbucket-branch-source-plugin/blob/24d9487c9dcdc6e5f00f9c891b162da3bba3cb3c/src/main/java/com/cloudbees/jenkins/plugins/bitbucket/BitbucketSCMSource.java#L1191-L1212

The equivalent method in github-branch-source is quite a bit different: https://github.com/jenkinsci/github-branch-source-plugin/blob/490693b59b83a4a82b0b94dd1ba2c7b5870be005/src/main/java/org/jenkinsci/plugins/github_branch_source/GitHubSCMSource.java#L2161-L2180

This change makes the method here look like the method in github-branch-source.

Tested manually with and without this change and it appears to work.

Your checklist for this pull request

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or in Jenkins JIRA
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Did you provide a test-case? That demonstrates feature works or fixes the issue.

<!-- Put an x into the [ ] to show you have filled the information below Describe your pull request below -->

Increment the Jackson version

Signed-off-by: Andrew Bayer [email protected]

• JENKINS issue(s):
  • Issue link or n/a
• Description:
  • ...
• Documentation changes:
  • Link to related jenkins.io PR or explanation for why doc change not needed
• Users/aliases to notify:
  • ...

• JENKINS issue(s):
  • n/a
• Description:
  • I'm working on tooling for converting Jenkinsfiles to JSON outside of a Jenkins instance, and there are a number of things that break as things stand now. This fixes those, by allowing for providing a ModelValidator implementation and a DescriptorLookupCache instance to ModelParser, and uses a fallback for the zero-arg agent model map if run outside of Jenkins.
• Documentation changes:
  • n/a - this isn't user-facing.
• Users/aliases to notify:
  • @bitwiseman

🤦

JENKINS issue(s):

• JENKINS-34987

Description:

Automatically splitting the pipeline script into multiple smaller parts makes it less likely for the resulting compiled class throw "Method code too large!" or "Class too large" exceptions during the class file generation phase of compilation.

Script splitting has two different strategies: method-grouped and closure-only. Closure-only is less effective but method-grouped splitting is not compatible with some groovy structures. In particular locally declared variables, such as such as def a = 1, are incompatible with the more effective method-grouped script splitting.

Before this change, any statements outside the pipeline directive would cause the plugin to switch to using the less effective closure-only script splitting.

This change does three things:

1. It uses the method-grouped script splitting unless it detects locally declared variables such as def a = 1 outside the pipeline {} directive.
2. If it detects locally declared variables such as def a = 1: a. it defaults to failing the run telling the user to add the @Field annotation to the declaration. b. If SCRIPT_SPLITTING_ALLOW_LOCAL_VARIABLES=true, it does not report an error, instead falling back to closure-only splitting.

Script splitting ignores other non-problematic statements such as method/function declarations or method calls. Note, this is experimental. There may be other structures aside from local variable declaration that are incompatible with script splitting. More testing is needed.

WARNING: this is a global change. If you install this version an have SCRIPT_SPLITTING_TRANSFORMATION=true, any declarative pipeline Jenkinsfile with a local variable declaration outside the pipeline block will fail. You may switch back to allowing locally declared variables by setting SCRIPT_SPLITTING_ALLOW_LOCAL_VARIABLES=true.

@abayer Do you plan to write a test?

@MarcosCela

If I understand correctly, we'll need to do the second approach in order for refresh to work for longer than the expiration time of the JWT Token. And JWT Tokens have a shorter life span than the GitHub App Tokens.

@abayer I'm seeing the same failure on #405.

Build failures look like infra issues.

@seregamorph Interesting. Is it possible it is only present on events?
This doesn't include it: https://api.github.com/repos/octocat/Hello-World/git/commits/7fd1a60b01f91b314f59955a4e4d4e80d8edf11d

I'd be okay with adding this if the javadoc clearly states that is only seen on events and we add @Preview @Deprecated annotations to it. I would also ask that you contact GitHub support and ask them to clarify the documentation.

username

@eplodn We are no longer making major changes to Blue Ocean except for security and regression fixes. Removing a component would be a major change.

@ugatenio I don't have much context in which to evaluate this. What you describe as the new behavior looks good, but I'm not sure how to validate it to make sure it doesn't cause a regression.

@olamy @cliffmeyers Any thoughts? The looks like a pretty safe change, but I'd like some other folks to look at it too.

Description

See JENKINS-63698.

Submitter checklist

• [x] Link to JIRA ticket in description, if appropriate.
• [x] Change is code complete and matches issue description
• [ ] Appropriate unit or acceptance tests or explanation to why this change has no tests
• [ ] Reviewer's manual test instructions provided in PR description. See Reviewer's first task below.

Reviewer checklist

• [ ] Run the changes and verified the change matches the issue description
• [ ] Reviewed the code
• [ ] Verified that the appropriate tests have been written or valid explanation given

<!-- Please describe your pull request here. -->

<!-- To mark your pull request as work in progress please create it as a draft pull request -->

Your checklist for this pull request

• [ ] Make sure you are requesting to pull a topic/feature/bugfix branch (right side) and not your master branch!
• [ ] Ensure that the pull request title represents the desired changelog entry
• [ ] Please describe what you did
• [ ] Link to relevant issues in GitHub or in Jenkins JIRA
• [ ] Link to relevant pull requests, esp. upstream and downstream changes
• [ ] Did you provide a test-case? That demonstrates feature works or fixes the issue.

<!-- Put an x into the [ ] to show you have filled the information below Describe your pull request below -->

So, why add these two lines?

To test this change locally:

Install the following incrementals: https://repo.jenkins-ci.org/incrementals/org/jenkinsci/plugins/pipeline-model-api/1.7.3-rc1872.9504c794d213/ https://repo.jenkins-ci.org/incrementals/org/jenkinsci/plugins/pipeline-model-definition/1.7.3-rc1872.9504c794d213/ https://repo.jenkins-ci.org/incrementals/org/jenkinsci/plugins/pipeline-model-extensions/1.7.3-rc1872.9504c794d213/ https://repo.jenkins-ci.org/incrementals/org/jenkinsci/plugins/pipeline-stage-tags-metadata/1.7.3-rc1872.9504c794d213/

(Sorry, yes, you need to do all four of them.)

Then via command-line ops or in Jenkins script console set the flag: org.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION=true

WARNING: this is a global change. If you install this version and have SCRIPT_SPLITTING_TRANSFORMATION=true, any declarative pipeline Jenkinsfile with a local variable declaration (def varName="value") outside the pipeline block will fail. This is intentional, keeping users from accidentally defeating the improved script splitting. The fix is to add an @Field annotation - @Field def varName="value". You may switch back to allowing locally declared variables by setting org.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_ALLOW_LOCAL_VARIABLES=true.

Yeah, that is not great behavior.
GHPullRequest is depending on GHIssue to make sure some fields are populated. This should probably be a check whether labels is null as with a number of other populate() behaviors.

The commit aspect is mentioned on line 8 above. I see you're trying to be clear. Maybe the suggestion below?

     * Gets the git user name for an author or committer on a git commit.