Regarding your additional questions: Can you rerun github pr ci if it fails. >
If you think the failure was due to an intermittent problem and want to retry, then you can rerun the check, for example, as shown below. However, if it is not an intermittent failure, such as a syntax error during compilation, then you can fix the problem in the current branch then commit the fix. This will automatically trigger a new series of checks as indicated above. You can perform this process iteratively as needed. In the PR shown above, after the checks have finished (pass or fail), you can examine the details of a specific check, for example the Maven build and test check: [image: Screen Shot 2023-03-07 at 22.27.55.png] Here you can rerun all checks (with *Re-run all jobs* button) or you can rerun a specific job, here the *build* job (yellow arrow). [image: Screen Shot 2023-03-07 at 22.28.34.png] You can also examine the log output for each task in a job, for example, the *Build with Maven* task, by uncollapsing the task (yellow arrow). [image: Screen Shot 2023-03-07 at 22.29.26.png] > If your changing something that wont affect CI such as a small typo, > documentation? > One you are proficient with running through the above workflow, you will find it doesn't take more than 2 to 3 minutes to perform all of the above. I do this routinely, probably 20 to 50 times per day on my *day job*. As a consequence, you don't mind doing this for even the smallest changes. The overall benefits to the team and the project are that this process enables consistency and auditable results while ensuring that code quality and security analyses can be kept current. I would agree that this process introduces some overhead beyond svn add && svn commit, but the benefits of having a tightly integrated CI with a project's repository are positive. It is also more up to date with current development processes and heightened security consciousness. For example, I was alerted to and fixed 7 security vulnerabilities in xmlgraphics-commons as a result of setting up this configuration. Lastly, if we are going to have some changes go through the PR process (and all of my changes will do so), then it will be inconsistent if some changes do not follow this process. In conclusion, I am essentially advocating that we adopt the Feature Branch Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow> . As an aside, I would actually prefer that we go as far as adopting the Gitflow Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow>; however, I am not advocating it at this time or in the foreseeable future. I happen to use the Gitflow Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow> in my *day job*, which encompasses dozens of teams using hundreds of GitLab repositories with GitLab CI and CD tools, where we have no problem with using the Gitflow Workflow <https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow> at all (notwithstanding the linked article's claim to the contrary). > > For large changes it is good to open a code review. > I agree we should consider a standard policy regarding when to use reviews. And when we do, the GH PR workflow process is well suited to enable this. However, at present, I have not enabled any review/approval requirements for merges, which is something we could do in the future. At present, I have configured branch protection on this repo as follows ( see .asf.yaml <https://github.com/apache/xmlgraphics-commons/blob/main/.asf.yaml>): [image: Screen Shot 2023-03-07 at 23.06.26.png] Also, note that I have not yet performed any additional configuration updates on the batik, fop, or fop-pdf-images repositories.
