Init #192
Closed
Init #192
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
Co-authored-by: Daniel Beck <[email protected]>
timja
commented
Jan 9, 2025
|
|
||
| private final int order; | ||
|
|
||
| private Group(int order) { |
There was a problem hiding this comment.
this is not very nice
timja
commented
Jan 9, 2025
timja
commented
Jan 9, 2025
There was a problem hiding this comment.
Lets try implement factories in a couple of plugins, like: https://ci.jenkins.io/job/Core/job/jenkins/view/change-requests/job/PR-10009/2/pipeline-graph/
…enkinsci#10138) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Basil Crow <[email protected]>
Co-authored-by: Basil Crow <[email protected]>
… no-op implementation is ok
timja
commented
Jan 10, 2025
…uild discarders (jenkinsci#10113) * initial commit * this change is not actually needed * rebuild
Small little PR to update the 'Copy' button animation. You now get a little more visual feedback that something has been copied successfully, the copy symbol now transforms into a check mark. **Before** https://github.com/user-attachments/assets/65e9c661-3465-4734-a67c-9ccbc66880a3 **After** https://github.com/user-attachments/assets/0486dc96-1e15-4974-832e-298b3a8a59e8 In doing so the 'Copied' tooltip has been dropped, happy to hear thoughts on this, I personally found it a little janky in how it replaced the existing tooltip on click. ### Testing done * Animation displays as expected, copying still works ### Proposed changelog entries - Update the 'Copy' button animation ### Proposed upgrade guidelines N/A <!-- Comment: Leave the proposed upgrade guidelines in the pull request with the "N/A" value if no upgrade guidelines are needed. The changelog generator relies on the presence of the upgrade guidelines section as part of its data extraction process. --> ```[tasklist] ### Submitter checklist - [ ] The Jira issue, if it exists, is well-described. - [x] The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see [examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade. - [x] There is automated testing or an explanation as to why this change has no tests. - [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, as appropriate. - [ ] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")`, if applicable. - [ ] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content Security Policy (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)). - [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials. - [ ] For new APIs and extension points, there is a link to at least one consumer. ``` ### Desired reviewers @jenkinsci/sig-ux <!-- Comment: If you need an accelerated review process by the community (e.g., for critical bugs), mention @jenkinsci/core-pr-reviewers. --> Before the changes are marked as `ready-for-merge`: ```[tasklist] ### Maintainer checklist - [x] There are at least two (2) approvals for the pull request and no outstanding requests for change. - [x] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change. - [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood. - [ ] Proper changelog labels are set so that the changelog can be generated automatically. - [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](jenkinsci#4387)). - [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)). ```
<!-- Comment: A great PR typically begins with the line below. Replace XXXXX with the numeric part of the issue ID you created in Jira. Note that if you want your changes backported into LTS, you need to create a Jira issue. See https://www.jenkins.io/download/lts/#backporting-process for more information. --> See JENKINS-75100 Now that the [disable by default of YUI](jenkinsci#10045) has been released for ~1 month with no complaints its time to start thinking about removing YUI itself. We're passed the baseline cut-off for the next LTS which was what @MarkEWaite requested that I wait for before removing YUI fully What I've left: * I've removed CSS where I think its safe but I haven't removed all mentions of `yui`. * `l:yui` I've changed it to do nothing but its used in a few unmaintained plugins, I could remove this, thoughts? * There's a few TODOs that say they could be cleaned up after yui was removed for the component, but hasn't been done yet ATH passed: jenkinsci/acceptance-test-harness#1884 Bom: jenkinsci/bom#4176 <!-- Comment: If the issue is not fully described in Jira, add more information here (justification, pull request links, etc.). * We do not require Jira issues for minor improvements. * Bug fixes should have a Jira issue to facilitate the backporting process. * Major new features should have a Jira issue. --> ### Testing done Clicked around a number of pages and didn't see anything wrong. <!-- Comment: Provide a clear description of how this change was tested. At minimum this should include proof that a computer has executed the changed lines. Ideally this should include an automated test or an explanation as to why this change has no tests. Note that automated test coverage is less than complete, so a successful PR build does not necessarily imply that a computer has executed the changed lines. If automated test coverage does not exist for the lines you are changing, you must describe the scenario(s) in which you manually tested the change. For frontend changes, include screenshots of the relevant page(s) before and after the change. For refactoring and code cleanup changes, exercise the code before and after the change and verify the behavior remains the same. --> ### Proposed changelog entries - Remove the Yahoo! User Interface library <!-- Comment: The changelog entry should be in the imperative mood; e.g., write "do this"/"return that" rather than "does this"/"returns that". For examples, see: https://www.jenkins.io/changelog/ Do not include the Jira issue in the changelog entry. Include the Jira issue in the description of the pull request so that the changelog generator can find it and include it in the generated changelog. You may add multiple changelog entries if applicable by adding a new entry to the list, e.g. - First changelog entry - Second changelog entry --> ### Proposed upgrade guidelines N/A <!-- Comment: Leave the proposed upgrade guidelines in the pull request with the "N/A" value if no upgrade guidelines are needed. The changelog generator relies on the presence of the upgrade guidelines section as part of its data extraction process. --> ```[tasklist] ### Submitter checklist - [ ] The Jira issue, if it exists, is well-described. - [ ] The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see [examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade. - [ ] There is automated testing or an explanation as to why this change has no tests. - [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, as appropriate. - [ ] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")`, if applicable. - [ ] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content Security Policy (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)). - [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials. - [ ] For new APIs and extension points, there is a link to at least one consumer. ``` ### Desired reviewers @mention <!-- Comment: If you need an accelerated review process by the community (e.g., for critical bugs), mention @jenkinsci/core-pr-reviewers. --> Before the changes are marked as `ready-for-merge`: ```[tasklist] ### Maintainer checklist - [ ] There are at least two (2) approvals for the pull request and no outstanding requests for change. - [ ] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change. - [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood. - [ ] Proper changelog labels are set so that the changelog can be generated automatically. - [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](jenkinsci#4387)). - [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)). ```
… no-op implementation is ok (jenkinsci#10140) <!-- Comment: A great PR typically begins with the line below. Replace XXXXX with the numeric part of the issue ID you created in Jira. Note that if you want your changes backported into LTS, you need to create a Jira issue. See https://www.jenkins.io/download/lts/#backporting-process for more information. --> While investigating a security issue a few months back, I noticed that our implementation of `AbstractUserDetailsAuthenticationProvider.additionalAuthenticationChecks` did not use the approach recommended in the superclass method's Javadoc, which was a bit concerning after looking at some of the branches in [this code](https://github.com/spring-projects/spring-security/blob/8a6e1297a1e3f3feca3639027f8cc225847970ec/core/src/main/java/org/springframework/security/authentication/dao/AbstractUserDetailsAuthenticationProvider.java#L122-L169). After some investigation it seems fine, but I think it is worth noting _why_ it is fine in case someone copies this code when creating a new security realm and they want to use Spring Security's user caching system. <!-- Comment: If the issue is not fully described in Jira, add more information here (justification, pull request links, etc.). * We do not require Jira issues for minor improvements. * Bug fixes should have a Jira issue to facilitate the backporting process. * Major new features should have a Jira issue. --> ### Testing done This PR only updates a comment. <!-- Comment: Provide a clear description of how this change was tested. At minimum this should include proof that a computer has executed the changed lines. Ideally this should include an automated test or an explanation as to why this change has no tests. Note that automated test coverage is less than complete, so a successful PR build does not necessarily imply that a computer has executed the changed lines. If automated test coverage does not exist for the lines you are changing, you must describe the scenario(s) in which you manually tested the change. For frontend changes, include screenshots of the relevant page(s) before and after the change. For refactoring and code cleanup changes, exercise the code before and after the change and verify the behavior remains the same. --> ### Proposed changelog entries N/A ### Proposed upgrade guidelines N/A <!-- Comment: Leave the proposed upgrade guidelines in the pull request with the "N/A" value if no upgrade guidelines are needed. The changelog generator relies on the presence of the upgrade guidelines section as part of its data extraction process. --> ```[tasklist] ### Submitter checklist - [ ] The Jira issue, if it exists, is well-described. - [ ] The changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developers, depending on the change) and are in the imperative mood (see [examples](https://github.com/jenkins-infra/jenkins.io/blob/master/content/_data/changelogs/weekly.yml)). Fill in the **Proposed upgrade guidelines** section only if there are breaking changes or changes that may require extra steps from users during upgrade. - [x] There is automated testing or an explanation as to why this change has no tests. - [ ] New public classes, fields, and methods are annotated with `@Restricted` or have `@since TODO` Javadocs, as appropriate. - [ ] New deprecations are annotated with `@Deprecated(since = "TODO")` or `@Deprecated(forRemoval = true, since = "TODO")`, if applicable. - [ ] New or substantially changed JavaScript is not defined inline and does not call `eval` to ease future introduction of Content Security Policy (CSP) directives (see [documentation](https://www.jenkins.io/doc/developer/security/csp/)). - [ ] For dependency updates, there are links to external changelogs and, if possible, full differentials. - [ ] For new APIs and extension points, there is a link to at least one consumer. ``` ### Desired reviewers <!-- Comment: If you need an accelerated review process by the community (e.g., for critical bugs), mention @jenkinsci/core-pr-reviewers. --> Before the changes are marked as `ready-for-merge`: ```[tasklist] ### Maintainer checklist - [x] There are at least two (2) approvals for the pull request and no outstanding requests for change. - [x] Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change. - [ ] Changelog entries in the pull request title and/or **Proposed changelog entries** are accurate, human-readable, and in the imperative mood. - [ ] Proper changelog labels are set so that the changelog can be generated automatically. - [ ] If the change needs additional upgrade steps from users, the `upgrade-guide-needed` label is set and there is a **Proposed upgrade guidelines** section in the pull request title (see [example](jenkinsci#4387)). - [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a _Bug_ or _Improvement_, and be labeled as `lts-candidate` to be considered (see [query](https://issues.jenkins.io/issues/?filter=12146)). ```
…4dc79fb_c458d (jenkinsci#10142) Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
timja
commented
Jan 13, 2025
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.
See JENKINS-XXXXX.
Testing done
Proposed changelog entries
Proposed upgrade guidelines
N/A
Desired reviewers
@mention
Before the changes are marked as
ready-for-merge: