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

Fix serverAuthenticationToken being required for configuration via CasC #124

Closed
wants to merge 10 commits into from

Conversation

Smasherr
Copy link
Contributor

This fix avoids the following error message

io.jenkins.plugins.casc.ConfiguratorException: serverAuthenticationToken is required to configure class hudson.plugins.sonar.SonarInstallation

when using a YAML configuration without serverAuthenticationToken

Copy link
Member

@henryju henryju left a comment

Choose a reason for hiding this comment

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

LGTM

src/test/java/hudson/plugins/sonar/CasCTest.java Outdated Show resolved Hide resolved
@Smasherr Smasherr force-pushed the master branch 2 times, most recently from e8a5f7b to 22fd288 Compare August 27, 2019 09:34
@oleg-nenashev
Copy link

Copy link

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

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

It is up to plugin maintainers, but from what I see it breaks binary compatibility while it could be avoided

@Smasherr
Copy link
Contributor Author

Should be fixed in CasC jenkinsci/configuration-as-code-plugin#1025

@Smasherr Smasherr closed this Aug 27, 2019
@thorin
Copy link

thorin commented Sep 28, 2019

@Smasherr jenkinsci/configuration-as-code-plugin#1025 has been merged.

But now @Nullable should be replaced with @CheckForNull on SonarInstallation to fix the configuration via CasC.

Any reason to prefer @Nullable over @CheckForNull ?

@Smasherr
Copy link
Contributor Author

Smasherr commented Sep 29, 2019

@oleg-nenashev Please review the latest state of this PR. Would you also be so kind to answer this?

Any reason to prefer @Nullable over @CheckForNull?

@ghost ghost assigned henryju Sep 30, 2019
@Smasherr
Copy link
Contributor Author

Smasherr commented Oct 5, 2019

Bump: any feedback?

@timja
Copy link
Contributor

timja commented Oct 5, 2019

@oleg-nenashev Please review the latest state of this PR. Would you also be so kind to answer this?

Any reason to prefer @Nullable over @CheckForNull?

CheckForNull is normally preferred as it has better integration into static code analysis frameworks like spotbugs AFAIK

pom.xml Outdated Show resolved Hide resolved
Smasherr and others added 2 commits October 5, 2019 16:09
Co-Authored-By: Tim Jacomb <t.jacomb@kainos.com>
Copy link
Contributor

@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.

LGTM @henryju?

@timja
Copy link
Contributor

timja commented Oct 5, 2019

The build is failing because it's untrusted I assume:
/home/travis/.local/bin/install: line 19: ARTIFACTORY_URL: unbound variable

@henryju
Copy link
Member

henryju commented Oct 7, 2019

@dbmeneses can you please take over this PR?

@Smasherr
Copy link
Contributor Author

Bump: merge it please

@timja
Copy link
Contributor

timja commented Oct 23, 2019

@Smasherr can you please resolve the conflicts?

@timja
Copy link
Contributor

timja commented Oct 23, 2019

Would be cool to have this merged first: #130

probably no harm in cherry-picking that into this PR as well

@timja
Copy link
Contributor

timja commented Oct 23, 2019

@henryju / @dbmeneses could we get this reviewed / merged please? We have users asking about this often

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi @Smasherr and @timja ,

Sorry this is taking a bit long. Let me do a final check. In the meantime, I added 2 small nitpicks about the code format.

protected String stringInLogExpected() {
return "credentialsId = test-id";
}
}

Choose a reason for hiding this comment

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

I see we forgot to link to our contribution guidelines for this project. Sorry about that.

Could you please reformat this code so it follows our code style (config for Eclipse and IntelliJ available here)? From the looks of it, I think only the indentation should be corrected.

Copy link
Contributor

Choose a reason for hiding this comment

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

I see we forgot to link to our contribution guidelines for this project. Sorry about that.

Could you please reformat this code so it follows our code style (config for Eclipse and IntelliJ available here)? From the looks of it, I think only the indentation should be corrected.

Checkstyle? 🙂

@henryju
Copy link
Member

henryju commented Oct 25, 2019

I looked again and seems fine to me. I'm just concerned about the use of @CheckForNull. In SonarSource we tend to use @Nullable. Is the meaning the same for CasC?

@timja
Copy link
Contributor

timja commented Oct 25, 2019

Nullable

See the discussion here, about CheckForNull and Nullable.
jenkinsci/configuration-as-code-plugin#1053 (comment)

The jenkins project tends to prefer CheckForNull as it has better integration with spotbugs. i.e. you must check a value for null if it could be null

@henryju
Copy link
Member

henryju commented Oct 25, 2019

We are not using Spotbugs but SonarQube ;) From CasC point of view, does it make a difference if we switch to @Nullable?

@timja
Copy link
Contributor

timja commented Oct 25, 2019

We are not using Spotbugs but SonarQube ;) From CasC point of view, does it make a difference if we switch to @Nullable?

Needs a code change in JCasC and a release, Oleg didn't seem terribly keen on Nullable but probably no big deal..

@Smasherr
Copy link
Contributor Author

Hey guys, nice to see finally some actions here. I've been on vacation and can do the requested changes to this PR tomorrow.

@Smasherr
Copy link
Contributor Author

@wouter-admiraal-sonarsource Hi, does it look better to you now?

@wouter-admiraal-sonarsource
Copy link
Contributor

@wouter-admiraal-sonarsource Hi, does it look better to you now?

Perfect, thanks. I'll run the QA one more time from #132, and we'll finally merge. Thank you for your patience and contribution 👍 !

pom.xml Show resolved Hide resolved
@Smasherr
Copy link
Contributor Author

@wouter-admiraal-sonarsource You're welcome! Would you be so kind and to do a release with this change anytime soon?

@Smasherr
Copy link
Contributor Author

Smasherr commented Nov 4, 2019

Status?

@nettworks-tooling
Copy link

Any news on this topic? Would be very cool if this would be merged soon as we spot issues at this point on our automated Jenkins master setup.

@wouter-admiraal-sonarsource
Copy link
Contributor

This was merged in #132. Thank you all for your help 👍

@Smasherr
Copy link
Contributor Author

Smasherr commented Nov 6, 2019

@wouter-admiraal-sonarsource good news, thanks! Now it would be great to have this in a release any time soon :-)

@Wurden
Copy link

Wurden commented Nov 21, 2019

I would like to add that it not only fails when serverAuthenticationToken is missing, it fails if any possible config parameter is missing, so for a working JCasC you need to include everything even though values are empty. Most other plugins have defaults and do not fail when config parameters are empty.
Just for reference, see below for working configurations. Hope this fix gets released soon.

sonarGlobalConfiguration:
  installations:
    - name: "my-sonarqube"
      serverUrl: "https://url-to-sonarqube.com/"
      serverAuthenticationToken: "" # Although we don't need any of below parameters, the Sonar plugin requires them to be present
      credentialsId: ""
      webhookSecretId: ""
      mojoVersion: ""
      additionalProperties: ""
      additionalAnalysisProperties: ""
      triggers:
        envVar: ""
        skipScmCause: false
        skipUpstreamCause: false

The same is the case for the sonarRunnerInstallation config, you also need to include everything there, even if empty.

tool:
  sonarRunnerInstallation:
    installations:
    - name: "my-sonarqube"
      home: "" # Sonar plugin requires home to be present as well
      properties:
      - installSource:
          installers:
          - sonarRunnerInstaller:
              id: "4.2.0.1873"

@Smasherr
Copy link
Contributor Author

Smasherr commented Nov 21, 2019

@Wurden The result of this change is that only 3 parameters remain required: name, serverUrl and triggers. The latter became optional in #137, so now only name and serverUrl are mandatory.

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