Hi @juanpablo-santos Thank you for your feedback. I'm aligned with your thoughts on transitioning to a single CI/CD system via GitHub Actions. Here's my action plan:
- *Single CI/CD System*: Agreed. I'll validate GitHub Actions' capabilities within two weeks and then start phasing out Jenkins. - *SonarQube Analysis*: Excellent idea. I'll integrate this into the renamed qa.yaml pipeline within a week. - *Static Site Deployment*: I'll investigate GitHub Actions solutions for this. I'm not yet familiar with how to accomplish this in GitHub Actions. - *Windows Build Errors*: I'll dig into this issue. - *Integration Tests*: I'll explore running these in headless mode. Any advice is welcome. I fully agree with you and Juan Pablo that we should not replace Jenkins until we have a fully functional GitHub Actions setup. This ensures that we have a fallback option in case the transition hits any snags. Hi Murray, Your caution is understandable, especially when considering a change to a system that is already functional. However, I'd like to highlight some key benefits that GitHub Actions can bring to our workflow: *Ease of Use*: GitHub Actions is integrated into GitHub itself, simplifying the CI/CD process by keeping everything in one place. This can make it easier for new contributors to get involved. *Flexibility*: GitHub Actions allows for more customized workflows, which can be particularly beneficial for complex projects. We can define multiple workflows for different scenarios, all within the same repository. Best regards, Arturo On Fri, Oct 20, 2023 at 8:59 PM Juan Pablo Santos Rodríguez < juanpablo.san...@gmail.com> wrote: > Hi Arturo! > > My 2c, > > I'm ok with the change, with a caveat: > > If we switch to GH actions, let's ditch the Jenkins build entirely, in > order to not have two different build/ci systems. This implies a number of > things > > - SQ analysis should be done from one of the pipelines, perhaps the codeql > one? So it would have to be renamed to qa.yaml or something like that > > - Also, currently, if the ci build is successful and we have a SNAPSHOT > version, we automatically deploy to repository.a.o, one of the pipelines > should also take care of that, not sure which. > > - Last, a successful build also triggers the build on charge of deploying > the static site and associated assets (javadocs, japicmp reports). IIRC, > infra provides support for these actions when working with either Jenkins > or GH actions, but don't have any pointer on how to do it on the latter. > > Of course we can keep the Jenkins build until all of these steps are > completed, but always having the final picture in mind (i.e., one build/ci > system). > > Said that a couple questions/wishes on the GH actions builds: > > 1) what kind of errors display the windows builds? I suspect that most > probably there's a problem with the test execution order (at least that's > what happened in other similar situations). Could we get a lot of any of > those builds? > > 2) would it be possible to also run the integration tests? They can be run > on headless mode, so we'd only need an additional chrome binary on the > build path. Don't know if it's possible though. > > > Thx + best regards, > juan pablo > > El jue, 19 oct 2023, 22:08, Arturo Bernal <aber...@apache.org> escribió: > > > Dear Team, > > > > I'd like to propose the addition of three new GitHub Actions workflows to > > enhance our CI/CD pipeline for the Apache JSPWiki project. Below are the > > details: > > > > 1. > > > > *Java CI Workflow*: Provides continuous integration support across > > multiple OS (Ubuntu, macOS) and Java versions (11, 17). It also caches > > Maven dependencies for optimized build times. > > 2. > > > > *Dependency Review Workflow*: Triggered on pull requests to review and > > ensure that dependencies are safe. > > 3. > > > > *CodeQL Workflow*: Provides continuous integration and code quality > > checks. > > > > These workflows are designed to automate and streamline our development > > process, making it more efficient. They will run on every push to the > > master branch and on every pull request, ensuring that our code is > > continuously tested and dependencies are reviewed. > > > > I've already created a pull request with these changes, which you can > > review here <https://github.com/apache/jspwiki/pull/299/files>. > > > > Here are the key files to be added: > > > > - CodeQL (codeql.yml) for continuous integration and code quality > > checks. > > - Dependency Review (dependency-review.yml) for dependency checks. > > - Java CI (maven.yml) for continuous integration across multiple OS > and > > Java versions. > > > > I'd appreciate your thoughts and feedback on this proposal. Are there any > > concerns or suggestions you'd like to share? > > > > Best regards, > > Arturo > > >
