Automated preview environments at pull requests

[dakar91]

How to use GitHub

• Please use the 👍 reaction to show that you are interested into the same feature.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Is your feature request related to a problem? Please describe.
Maintainers are reviewing pull requests only by looking at the code or pulling the branch locally, building and testing it there, which is time consuming.

Describe the solution you'd like
I would like to propose the integration of automated preview environments at pull requests in Nextcloud. This feature would allow contributors to have a dedicated environment automatically created for each pull request, enabling them to test their changes in a controlled environment without impacting the main instance. It would streamline the review process, enhance collaboration, and reduce the risk of introducing bugs or regressions.

Describe alternatives you've considered
One alternative would be manual setup of preview environments for each pull request, but this would require significant time and effort from contributors and reviewers. Another option would be relying solely on local testing environments, but this approach may not accurately reflect the production environment and can lead to inconsistencies.

Additional context
Automated preview environments for Pull Requests would provide several benefits:

• Simplified testing: Contributors can easily verify the functionality and compatibility of their changes in an isolated environment.

• Improved collaboration: Reviewers can access the preview environment to test and validate pull requests without affecting the main instance.

• Efficient feedback loop: Automated preview environments facilitate faster feedback cycles between contributors and reviewers, speeding up the overall development process.

• Reduced risk: By testing changes in dedicated environments, the risk of introducing bugs or regressions into the main instance is minimized.

Bunnyshell's platform offers a comprehensive solution for automated preview environments, which could be seamlessly integrated into Nextcloud's pull request workflow. This feature would greatly enhance the development experience for contributors and reviewers, ultimately leading to higher-quality contributions and improved stability in Nextcloud.

Bunnyshell will implement this feature and cover the infrastructure costs as part of our Open Source initiative if it's considered to be of interest by maintainers.

[kesselb]

Updated the link to Bunnyshell.

[dakar91]

Adding more context here:

• github workflow example - https://github.com/aris-bunnyshell/demo-books-php/tree/main/.github/workflows
• environment definition example - https://github.com/aris-bunnyshell/demo-books-php/blob/main/.bunnyshell/templates/docker-compose/bunnyshell.yaml

Bunnyshell is providing free infrastructure to preview PRs for open source projects..
Our team @bunnyshell and @bunnyshellosi are ready to help implement the initial pipeline to get you started!

If interested, some external contact info would be great to sync faster or please email hello@bunnyshell.com

[dakar91]

Hey @nickvergessen maybe you could have a quick look at this issue since you've been working lately with the github workflows? We'd love to help out. Thank you.

[nickvergessen]

Hi there,

checked a bit with others internally and we are not sure this is beneficial for us at the moment.
One of the main points is that every developer has a different setup with different database, apps, user backend, etc. So every reviewer tests more/different aspects which is quite beneficial.
If there would be a one-click thing available and every used that, no one would run it locally any more and instead every deverkio tests with the same setup and the cross compatibility issues are only noticed much later or even after releasing.

Also from an environmental perspective 🍃 I see a lot of additional energy being burned to create ad-hoc installations that then lie around (or worst are kept up to date) for days/weeks and are never visited again.

But that's only my personal view.

[dakar91]

@nickvergessen thanks for the input:

• if it's beneficial to test multiple setups, then perhaps we can spin up a number of different stacks and run tests agains them when the PR is opened.
• regarding the environmental perspective, when the PR is opened a preview environment is built and deployed and then it can be automatically stopped (replicas down to 0 in k8s lingo) until the core maintainer can post a command on the PR and the environment would be re-deployed right then. This way the environment would run initially to make sure the deployment is successful and then it would only run for the period when it's actually being used.

Please let me know if that approach would be interesting.

I noticed @marcelklehr @EWouters liked the initial issue comment, maybe you can also share your opinion.

Thank you.