Simplify Config File Creation and Project Scaffolding Process

[georgetayqy]

What feature(s) would you like to see in RepoSense

Currently, the only way to create a config file is to create the underlying CSV or JSON file and populate it manually. This process might not exactly be user-friendly to those who are not tech-savvy (or even to those who are).

We could perhaps look into providing a service to allow users to create config files through an interactive GUI, allowing them to create config files, or even fully scaffolded RepoSense instances that users can run as is.

Is the feature request related to a problem?

No.

If possible, describe the solution

A proof of concept has been set up on this repo and the application is accessible here.

The application is set up using Docker on an AWS EC2 instance attached to an Auto-Scaling Group, backed by an Application Load Balancer. Please do not try to stress test it as the ASG is not configured to handle large volumes of traffic at the moment to keep costs low.

The application is also limited to config file creation at the moment, scaffolding may be implemented sometime in the future if this project is deemed viable by the dev team.

If applicable, describe alternatives you've considered

We could also make this a TUI tool developed in Java and package it alongside RepoSense to avoid provisioning resources and paying for cloud services.

Additional context

This application is developed in Python using Streamlit and pandas.

[gok99]

Some exploration has been done before into RepoSense Wizards, with limited success: #1430, #1715 (@MarcusTXK and @vvidday can probably describe the issues better).

Something simple like a streamlit UI seems like a good first approximation to get a sense of what this might look like. We could have it be a locally hosted web interface that is started with a CLI flag, like we do with reports. Are there particular benefits to hosting it ourselves other than RepoSense installation?

[damithc]

Also keep in mind that our target users are programmers who are tech savvy enough to use Git. So, JSON and csv formats themselves shouldn't be too daunting to them. The tedious (but not complex) part is gathering the required info and putting them in the right places. In particular, users might not be aware of the GitHub usernames they used.

[georgetayqy]

@gok99 One main benefit would be that anyone could use the tool to generate a fully scaffolded project (repository cloned with the necessary config files pre-initialised) without first cloning the project, saving the user some time. The other benefit would be to avoid further cluttering the user's system since Streamlit requires Python, meaning we might need to add Python to our list of dependencies. Moving it to the cloud/some web hosting platform would mean that there is less work to be done on our end to check if the Python packages would conflict with our other Java/NodeJS packages in any way, in a sense decoupling the project scaffolding tool from the main reporting tool.

However, there are also a few challenges that we might need to consider:

1. Cost of hosting the app

On AWS, while ALBs and ASGs are completely free to use, along with EC2 instances (as part of the 12-month free tier), the use of a public Elastic IP or domain name for accessing the app is charged. From my experience, it costs around 40 cents per day to keep a single free tier EC2 instance running 24/7 behind an ALB that is deployed in 3 AZs. Costs will only increase if we try to increase the number of EC2 instances that we wish to serve the app out of or increase the overall availability of our app by deploying it in different Regions, which can become quite costly rather fast. There might be cheaper/free options like Heroku, but I have not explored them yet.

2. Isolation of scaffolds

Currently, as a proof of concept, the configuration files and cloned repository are stored on disk before it is downloaded by the user. I am not sure if accessing the app from different endpoints would fork instances of the app, or if it will reuse the same instance, thereby causing users to unintentionally download other's scaffolded projects, or overwriting changes made by other users who are using the app at the same time. This might be a compelling reason to make this a local application rather than a web application to avoid this complication.

---

@damithc I understand, perhaps we could pivot from helping users fill in the YAML/JSON/CSV files, to helping users discern what fields they need to include quickly, without really needing to read the user guides, by using prose to describe what each field represents?