Fix upstream conflict #187
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…n in OAuth2SsoConfig when oauth2 is enabled (spinnaker#1492) Previously in spring 2.2.5, if oauth2 is enabled there is no circular dependency on ExternalAuthTokenFilter bean in OAuth2SsoConfig. In spring 2.2.13, if oauth2 is enabled there is a circular dependency error on ExternalAuthTokenFilter bean. This circular dependency results in an error when the gate application tries to start up. The application fails with error: BeanCurrentlyInCreationException: Error creating bean with name 'OAuth2SsoConfig': Bean with name 'OAuth2SsoConfig' has been injected into other beans [externalAuthTokenFilter] in its raw version as part of a circular reference, but has eventually been wrapped. To fix this error, add the Component annotation to ExternalAuthTokenFilter and remove the ExternalAuthTokenFilter bean from OAuth2SsoConfig. Co-authored-by: David Byron <dbyron@salesforce.com>
…aker#1453) Co-authored-by: Justin Field <justin.field@armory.io> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: Justin Field <justin.field@armory.io> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Co-authored-by: root <root@265713e22300>
Co-authored-by: root <root@ca7e6659c3b3>
Co-authored-by: root <root@7e927306ac3d>
Co-authored-by: root <root@01b270ba5f94>
Co-authored-by: root <root@73790eeb50df>
Co-authored-by: root <root@a229fbda21b3> Co-authored-by: Matt <6519811+mattgogerly@users.noreply.github.com>
* feat(web): Expose experimental account storage API This adds some of the REST APIs introduced in the experimental account storage API in Clouddriver to Gate. Initially, these APIs are only available for admins. * Combine account and credentials endpoints * Add docs on AccountDefinition * Add alpha annotations
Co-authored-by: Cameron Motevasselani <cameron@armory.io>
* fix(gate/web): Fix typo in PreAuthorize annotation It appears that some variables were renamed while I worked on the PR and didn't update the annotations to match. * fix(gate/core): Fix retrofit signature error
…aker#1514) This fixes an authorization check error where Jackson knows how to handle the `name` property of an account definition, but SpEL does not see the property. Now the PostFilter annotation should work equivalently to the same filter check in Clouddriver.
Co-authored-by: root <root@d38215f0a8da>
During setup of spinnaker authentication with oauth2 a common hurdle is a redirect loop. For example: spinnaker/spinnaker#5794 spinnaker/spinnaker#1630 Also, many threads in Slack discuss these problems. In fact this appears to be a common pitfall for the spring-security-oauth2-autoconfigure library in general. A light refresher on the ouath2 flow in play here seems worthwhile. The user is redirected from `/login` in gate to the external auth provider (google, github, etc.) and after successfully authenticating they are redirected back to the gate `/login` endpoint but this time with a code parameter that is to be used to request an access token. This request can fail for a variety of reasons, and if it does, the underlying spring library triggers a redirect to the `/error` endpoint. What causes the redirect loop for gate in particular (and for other users of the library in a similar fashion) is that the WebSecurityConfigurerAdapter in play is treating `/error` as an authenticated path and so instead of just returning with a 401, it re-redirects to `/login` and the redirect loop continues. My thought is that instead of a redirect loop, simply allowing the 401 to be returned will be a stronger more helpful signal as to what is going on. Hopefully it will save future first-time installers headaches. Spinnaker docs have included several troubleshooting hints and tips for how where you terminate SSL affects configuration etc. Even after following all of these and lots of spelunking through spinnaker github issues and combing over threads in slack, I found myself still experiencing a redirect loop even though I had applied all the combined wisdom that was applicable to my setup. As it turns out, I had a bad copy/paste of my client secret in my configuration. So the request to turn the code from google into an access token from google was failing with a 401. After much debugging and deep diving into the spring security code I found that had I turned on DEBUG in gate for these classes in gate-local.yml: ``` logging: level: org.springframework.security.web.authentication.SimpleUrlAuthenticationFailureHandler: DEBUG org.springframework.security.oauth2.client.filter.OAuth2ClientAuthenticationProcessingFilter: DEBUG ``` Then I would have seen in the logs that a 401 response was returned from google and perhaps it would have caused me to look closer at my botched client secret configuration. I think perhaps we don't want to require that all operators of spinnaker become spring-security-oauth2 experts. So I'm proposing adding `/error` to the list of paths in gate that aren't treated as authenticated. Thus short-circuiting the redirect loop and bringing to light helpful troubleshooting info that was previously more or less swallowed.
…ct resolution while upgrading the spring-boot 2.3.x (spinnaker#1505) * fix(dependency): Introducing spring dependency management gradle plugin Spring boot has moved to gradle based dependency management from v2.3.x. This change has brought issue of conflict resolution failure of the Jackson-bom version and kotlin-bom version with gate service when it consumes the maven-bom generated by kork. The issue details are available in given link. https://docs.google.com/document/d/1Ck4KeoB1ER0aQUTnf3e-x-M3i2Ur0It7YaaxEMiMXls/edit To resolve this issue while upgrading gate service with spring v2.3.x, we must require the spring dependency management gradle plugin. * Revert "fix(dependency): Introducing spring dependency management gradle plugin" This reverts commit b3b2c9e. * fix(dependency): Issue with jackson-bom and kotlin-bom version conflict resolution while upgrading the spring-boot 2.3.x. The root cause of this issue is uncontrolled conflict resolution of jackson-bom and kotlin-bom dependency version imported from external maven BOM provided by kork-bom, as per the gradle documentation https://docs.gradle.org/6.9.1/userguide/platforms.html#sub:bom_import, we can use gradle enforcedPlatform closure as part of the implementation to strictly adhere the versions of direct and transitive dependencies imported BOM. implementation(enforcedPlatform("io.spinnaker.kork:kork-bom:$korkVersion"))
Co-authored-by: root <root@92ccf252161e>
Co-authored-by: root <root@8e952337838c>
Co-authored-by: root <root@e15a7ff336aa>
Co-authored-by: root <root@00e70a80e3dd>
Co-authored-by: root <root@4cdab225ba98>
Co-authored-by: root <root@2bf6cb9b4370>
Co-authored-by: root <root@69a0efe35201>
…ker#1529) to Google Artifact Registry see: spinnaker/rosco#841 Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
- collapse version info gathering steps into single `build_variables` step - collapse version info parts into single string and use everywhere. - use short git sha: `(git rev-parse --short HEAD)` Note `build.yml` versioning is not compatible with Debian package building as gradle plugin enforces `^[0-9]+`. We don't publish master branch or release-* branches to GAR apt repository though. Prefixing the version with `<tag>-dev-` or something and publishing Debian packages is possible but may pollute `apt-cache policy spinnaker-rosco` output and overall be unnecessary with regular releases.
…lugin to actually not be supported (spinnaker#1532) Before this, a gate version >= 2.0.0 would cause versionNotSupportedPlugin to get used, causing tests to fail, and making it impossible to e.g. release gate.
I wanted to avoid confusion between a git tag `X` building version `X` and a master or release branch building version `X-dev-*` but it seems unavoidable. SemVer is required by plugins. See constraint: https://github.com/spinnaker/kork/blob/5dc6bb98615667f1b4f3e18445c1651d773c9f6b/kork-plugins/src/main/kotlin/com/netflix/spinnaker/kork/plugins/SpinnakerServiceVersionManager.kt#L47 changes: - fetch full git repository so that we can access previous tag in branch. Convert `release.yml` to this method instead of `run: git.. --unshallow`. - use previous git tag as start of version string. Cut the 'v' prefix from the tag, 'v1.2.3' -> '1.2.3' as required for Plugins (and Debians fwiw): `Caused by: Unexpected character 'LETTER(v)' at position '0', expecting '[DIGIT]'` - append `-dev-<branch_name|'pr'>` to designate that it is not an official version. The short git SHA and date time are NOT present on release versions (eg: 1.2.3) so that also differs. - do this version setting in `pr.yml` as well so we might pick up version issues in PR's and not just at merge.
Co-authored-by: root <root@3f84b148af75>
Co-authored-by: root <root@87e31b5c1a0c>
This normalizes the type discriminator in account definitions to match that of account credentials instances (i.e., the type of CredentialsDefinition instance and Credentials instance are both specified through the "type" property). This also removes redundant authorization annotations that are better enforced by AccountDefinitionService in Clouddriver. Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
|
This PR is rejected because reference to JIra ticket does not exist in the comments section of this PR. Close the PR, add Jira ticket number in comments, reopen the PR to trigger a new pipe in spinnaker.Reviewers approve only after jira reference is added. |
|
This PR triggered this build in this execution, please wait for it and child pipelines to succeed before merging: https://isd.prod.opsmx.net/deck/#/applications/gcp-gitprtrigger/executions/details/01FZG2B9NAMR9DMHW4Y7SSG4ZA |
|
This PR triggered this build in this execution, please merge to master only if this succeeds: https://isd.prod.opsmx.net/deck/#/applications/gcp-gitprtrigger/executions/details/01FZG2BJ74K8JSBMTYKP0PJY6G |
|
SUCCESSFUL RunTestJar RESULT: Total tests run: 196, Failures: 1, Skips: 0 Reviewers , this PR did not cause the failures in https://jenkins.opsmx.net:8181/jenkins/job/Dev-run-tests-on-gitpr-parallel/ws/emailable-report-2381.html |
|
This PR triggered this build in this execution, please wait for it and child pipelines to succeed before merging: https://isd.prod.opsmx.net/deck/#/applications/gcp-gitprtrigger/executions/details/01FZG397PT4D9EKRC967G9FNEV |
|
This PR triggered this build in this execution, please merge to master only if this succeeds: https://isd.prod.opsmx.net/deck/#/applications/gcp-gitprtrigger/executions/details/01FZG39SZXN0YX90A6C2KGN3K1 |
|
SUCCESSFUL RunTestJar RESULT: Total tests run: 196, Failures: 1, Skips: 0 Reviewers , this PR did not cause the failures in https://jenkins.opsmx.net:8181/jenkins/job/Dev-run-tests-on-gitpr-parallel/ws/emailable-report-2383.html |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We prefer small, well tested pull requests.
Please refer to Contributing to Spinnaker.
When filling out a pull request, please consider the following:
Note that we are unlikely to accept pull requests that add features without prior discussion. The best way to propose a feature is to open an issue first and discuss your ideas there before implementing them.
https://devopsmx.atlassian.net/browse/OP-13600