kavignon / developer-senzu-bean

A dotnet CLI supporting power users searching for ways to avoid executing redundant steps in the environment regarding cleanup and setup before executing programs.

Hi there 👋

My name is Kevin Avignon, and I am a senior software developer based in Montreal, Canada. I used to be a board member for the F# Software Foundation (FSSF). I led for 2 years the educative efforts for our international mentorship program and over that time, I had community members engaged with me as we built a platform to do match making between applicants (mentors/mentees).

You can find a list below of what I'm currently focused on:

• Exploring BEAM, Rails & Elm as I'm writing the online book Beware of Dragons

• I write posts on my technical blog from time to time.

  

developer-senzu-bean's Issues

Provide a CLI commands to clean a Git local repository

There can be multiple pitfalls surrounding the use of a given Git repository on a local machine. For instance, your code builds and runs on your local machine but fails in the CI server for some reason, or there are some lingering problems when switching branches, etc.

As a power user, I would like a CLI command that would do the following actions to clean my environment before I to my next move:

• Pruning old local branches from my machine,
• Resetting my branch,
• Executing a garbage collection in Git,
• Get rid of untracked and temporary files.

There can be times where a developer wouldn't wish to do everything in the aforementioned scenario. For that purpose, it would be easier to provide a CLI command executing all of those operations and dedicated commands for each activity related to cleaning a Git environment.

Show a progress bar whenever executing an action in the CLI

To give the user a sense of where they are in a given operation, it is imperative to give them some feedback of what's happening. For instance, when executing the action abstracted in #2, it would be great to see how the operation is doing overall while seeing also how the individual items are progressing.

Provide framework for developers to bind their automation as supported operations of DBS

There can be times where there are specific manual commands that need to be run by developers unknowingly of others. When that time arises, then they decide they're fed up with it and they tend to create scripts that will take care of the main gist without having to reminder all the specific details.

One problem that can come is whenever you need to remember the specific order to run the automation or why even you were running it if you're pulled in another project then have to come back to the old one after quite some time.

Here, this tool would propose that you provide your script along with the title of the automation. If you need multiple scripts to be executed in a specific order, you'll also have the chance to do so. Then, just activate the CLI command from the tool and you'll be golden :)

Create GitHub Action file and establish CI/CD pipeline

As for like any project, we want to make sure that whatever is in a pull request is of sound quality before merging it in. So, we'll want a basic CI pipeline which will take of the following:

• Restores the packages used by the executable (dotnet restore)
• Validates that the solution can build (dotnet build)
• Confirms that all the tests are successful across every test project (dotnet test)
• Publishes the executable to a zip file that can be distributed on this repository (dotnet publish)

Deploy DSB as a single file executable for WIN-64

To remove the number of binaries to deal with to run the executable on a Windows machine (MVP remember), we'll move towards the model of a single file executable.

Add a configuration for custom programs to keep track of

In a similar fashion as #2, a power user may have specific needs for what needs to be updated when cleaning and setting up their environment before executing specific programs.

The reason why there is a separation between custom and default programs is that there are more chances that every default program needs to be updated to the latest version whenever we can find an update, we might feel the same towards all the programs this tool tracks.

Here, we can give a space for users to not only provide a one-time update for specific programs but also a specific version if that can be found from the tool.

Setup the project

To set up the project, here's the checklist of items that need to get done

• Create the Visual Studio solution,
• Add .gitignore
• Add a console application in F#,
• Add a test project,
  Make sure that the project can be deployed with Docker,
• Add Console.Spectre as a development dependency to the console application,
• Add Argu as development dependency to the console application,
• Add Akka.NET as a development dependency to the console application.

Design the UI/UX of the EXE with Console.Spectre

Enable application modes to be ran concurrently by default

While executing commands on the tool, all those triggered events should be running in parallel in the background. This allows for more efficient workflows while doing the clean-update-set-and-run (CUSR) loop for developers.

Of course, being an open framework, developers who prefer to run things sequentially should also have the option made available for them.

Allow CLI commands to be executed either sequentially or concurrently

There can be times where there are a few steps that need to occur in a precise set of steps and other times where a developer would want to see happen at the same time to be as efficient as they could be.

With an F# environment and either the MailboxProcessor or Akka.NET, this shouldn't be too hard to obtain.

Define what are default programs, how to download + install them and keep them updated through the CLI

The DSB has default pre-occupation to think and care about. To that end, the system must define what are those default programs that .NET developers would care about such as:

• Git,
• .NET,
• NuGet

As a power tool user, I would like for these things to be hidden from me by default and only exposed if I wished for it. Of course, if the framework exposed through the configuration file isn't respected when extended by end-users, only care for the items that do respect it and then alert the user of the existing problem(s).

An idea could be to support a specific file describing

• What are the default programs
• Where can we download the updated version of a specific program

This configuration file should be accessible for developers who want to add more programs as a default program to care about.
Because we have default programs that don't depend on their respective updates to co-exists, I would then suggest that, whenever there's a need to update an environment, make all these updates in parallel as the default behavior. As we provide CLI commands to the end-users, we can also let them make specific updates to the default programs in the configuration file.

Another requirement: Whenever we install a program on a machine, make sure those installs are done silently (no interactions with the end-user) if possible.

Allow .NET developers to switch their .NET SDK from the CLI for their given project

There can be times where developers need to move between different SDKs and observe how their application(s) is(are) behaving.
Instead of making things manual and tedious, it should easy and automated. This could very well be part of a workflow that sets up a given .NET project.