Pre-commit filtering has come up on previous discussions as well and is an obvious improvement. I've opened BEAM-4445 [1] for this and assigned it to myself.
[1] https://issues.apache.org/jira/browse/BEAM-4445 On Fri, Jun 1, 2018 at 10:01 AM Kenneth Knowles <[email protected]> wrote: > +1 > > Can we separate precommit filtering and get it set up independent from > this? I think there's a lot of good directions to go once it is the norm. > > On Thu, May 31, 2018 at 9:25 PM Thomas Weise <[email protected]> wrote: > >> Very nice, enthusiastic +1 >> >> On Thu, May 31, 2018 at 3:24 PM, Scott Wegner <[email protected]> wrote: >> >>> Thanks to everyone who reviewed the doc. I put together a plan based on >>> the initial feedback to improve website automation reliability. At a >>> glance, I am proposing to: >>> >>> * Migrate website source code to the main apache/beam repository >>> * Discontinue checking-in generated HTML during the PR workflow >>> * Align to the existing apache/beam PR process (code review policy, >>> precommits, generic Git merge) >>> * Filter pre-commit jobs to only run when necessary >>> * Add a post-commit Jenkins job to push generated HTML to a separate >>> publishing branch >>> >>> Please take another look at the doc, specifically the new section >>> entitled "Proposed Solution": https://s.apache.org/beam-site-automation >>> I'd like to gather feedback by Monday June 4, and if there is consensus >>> move forward with the implementation. >>> >>> Thanks, >>> Scott >>> >>> >>> Got feedback? tinyurl.com/swegner-feedback >>> >>> On Tue, May 29, 2018 at 4:32 PM Scott Wegner <[email protected]> wrote: >>> >>>> I've been looking into the beam-site merge automation reliability, and >>>> I'd like to get some early feedback on ideas for improvement. Please take a >>>> look at https://s.apache.org/beam-site-automation: >>>> >>>> > Apache Beam's website is maintained via the beam-site Git repository, >>>> with a set of automation that manages the workflow from merging a pull >>>> request to publishing. The automation is centralized in a tool called >>>> Mergebot, which was built for Beam and donated to the ASF. However, the >>>> automation has been somewhat unreliable, and when there are issues, very >>>> few individuals have the necessary permissions and expertise to resolve >>>> them. Overall, the reliability of Beam-site automation is impeding >>>> productivity for Beam-site development. >>>> >>>> At this point I'm seeking feedback on a few possible solutions: >>>> >>>> 1. Invest in improvements to Mergebot reliability. Make stability >>>> tweaks for various failure modes, distribute Mergebot expertise and >>>> operations permissions to more committers. >>>> 2. Deprecate Mergebot and revert to manual process. With the current >>>> unreliability, some committers choose to forego merge automation anyway. >>>> 3. Generate HTML only during publishing. This seems to be newly >>>> supported by the Apache GitPubSub workflow. This would eliminate most or >>>> all of the automation that Mergebot is responsible for. >>>> >>>> Feel free to add comments in the doc. >>>> >>>> Thanks, >>>> Scott >>>> >>>> >>>> >>>> Got feedback? tinyurl.com/swegner-feedback >>>> >>> >>
