Re: Improving Dependabot Automation Under New Workflow Requirements
Thanks for chasing this Piotr. Given the recently stagnating Log4j maintainer time, the workflow of verifying dependabot PRs, adding associated changelog entries, and automatically merging upon success was a big time saver for us. I'd really appreciate it if we can bring it back. In GHA workflows, we refer to a reusable as simple as `/@`. Given this will only be used by a `logging-parent` reusable workflow, can't we place these sources to the `.github/actions` folder in `logging-parent`, and access it from there? If you say PAT will solve the workflow triggering issue, please proceed with creating the associated INFRA ticket. (I'd appreciate it if you can tag me there so that I can follow its implementation.) On Sat, May 10, 2025 at 10:32 PM Piotr P. Karwasz wrote: > Hi all, > > As expected, the introduction of required reviews and required checks > has made our "automatically merge Dependabot PRs" workflow less > automatic. Currently, for each Dependabot PR: > >* The commit that adds a changelog entry does not trigger the build > workflow and therefore fails the required checks. Amending the commit > manually (which would trigger the workflow) isn't possible through the > GitHub UI. >* A review is required. >* We must merge the PR manually once all checks pass. > > That said, these new security restrictions don’t necessarily mean more > manual work. There are ways we can streamline the process: > >* Dependabot Grouping: We can enable the grouping feature to > consolidate updates into a single weekly PR. While our current changelog > script doesn’t handle multiple updates per PR, I’ve created a custom > GitHub Action[1] that does. >* Auto-merge Support: GitHub’s auto_merge feature can automatically > merge Dependabot PRs once all required checks and reviews are satisfied. > My recent update to .asf.yaml enables this. >* Workflow Triggering with PAT: We can request a personal access > token (PAT) from INFRA to use in our changelog-adding workflow. Unlike > GITHUB_TOKEN, a PAT will trigger required workflows. > > I’d like to get your thoughts on a couple of related suggestions: > >* Migrating ppkarwasz/logging-actions to an Apache Logging repo — > either as part of logging-parent or as a standalone repo. I'm not sure > if such GitHub Actions would require a formal ASF release process. >* Requesting a PAT from INFRA to be used in workflows that modify > Dependabot PRs (e.g., to add changelog entries and trigger builds). > > Let me know what you think! > > Piotr > > [1] https://github.com/ppkarwasz/logging-actions > [2] https://github.com/apache/infrastructure-asfyaml/pull/66 >
Re: Improving Dependabot Automation Under New Workflow Requirements
Hi Volkan, On 13.05.2025 11:06, Volkan Yazıcı wrote: > Thanks for chasing this Piotr. Given the recently stagnating Log4j > maintainer time, the workflow of verifying dependabot PRs, adding > associated changelog entries, and automatically merging upon success was a > big time saver for us. I'd really appreciate it if we can bring it back. Thank you for implementing the first version of the action! > In GHA workflows, we refer to a reusable as simple as > `/@`. Given this will only be used by a > `logging-parent` reusable workflow, can't we place these sources to the > `.github/actions` folder in `logging-parent`, and access it from there? I guess it should work. I'll make a PR for that. > If you say PAT will solve the workflow triggering issue, please proceed > with creating the associated INFRA ticket. (I'd appreciate it if you can > tag me there so that I can follow its implementation.) I created the ticket: https://issues.apache.org/jira/browse/INFRA-26820 I don't see any major security issues in our usage pattern of the PAT, but we might need to motivate the request more thoroughly. Piotr
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user ElaHuskovic68 added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 hi @ppkarwasz - thank you for your answer. This is third party application, I dont have source code, only war file which contains 1.x version of log4j jar file. I checked with Owner and it looks like it wont work with newer jar file, proper migration has to be done from their end. Due to vulnerability of log4j it is recommended to upgrade on new version. Since I already have application with log4j 2.17.1 - though it could be the same version. Anyway, thanks for your reply. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13134691 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user perry2of5 added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 Some people have been known to recommend Reload4j 1.2.18 as a replacement for log4j 1.2.17 GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13135934 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
Re: [D] log4j-1.2.13.jar substitution in v.2.17.1 [logging-log4j2]
GitHub user lalo-mx added a comment to the discussion: log4j-1.2.13.jar substitution in v.2.17.1 > Some people have been known to recommend Reload4j 1.2.18 as a replacement for > log4j 1.2.17 https://reload4j.qos.ch/ > Initiated by Ceki Gülcü, the original author of Apache log4j 1.x, the > reload4j project is a fork of Apache log4j version 1.2.17 with the goal of > fixing pressing security issues. Reload4j is a binary compatible, drop-in > replacement for log4j version 1.2.17. By drop-in, we mean that you can > replace log4j.jar with reload4j.jar in your build with no source code > changes, no recompilation, nor rebuild being necessary. > > The reload4j project offers a clear and easy migration path for the thousands > of users who have an urgent need to fix vulnerabilities in log4j 1.2.17. GitHub link: https://github.com/apache/logging-log4j2/discussions/3656#discussioncomment-13136008 This is an automatically sent email for dev@logging.apache.org. To unsubscribe, please send an email to: dev-unsubscr...@logging.apache.org
