Document the process to test a new "unreleased app"

[00willo]

As a new contributor who is familiar with git but not yet across everything in Shuffle, I want to test or try out a new or update before it is released so I can provide feedback before it's merged and released.

I'd expect this to outline the steps I need to do to test an application and restore the instance to the previous state.

Maybe something like this???

=============

Procedure to test a new shuffle-app from github repo prior to release

This procedure is based on a docker-compose deployment as per the documentation.

NOTE: This also assumes you've cloned the main Shuffle repo directly and not your fork. Adjust the origin to your "upstream" ref if you're working off a fork.

To test a new app

1. fetch the pull request

   git fetch origin refs/pull/279/head:pull_279
   git checkout pull_279

2. place a copy of the specific app in volume mount location for ${SHUFFLE_APP_HOTLOAD_LOCATION}/shuffle/shuffle-apps
3. reload the App via the UI on the Apps page. This will hotload the app to be tested into shuffle.
4. provide any necessary feedback in the PR as required.

NOTE: If this is an updated app, it will replace the current latest version of the app that you had prior to hotloading this updated version. Usual docker There is no need to bump the version of the folder of the api.yml. With this method a new version of container is built and replaces the previous one you had.

To remove the test app and restore the previous one

This will trigger the latest released version of the app's container to be built again.

1. delete the app from the hotload folder
2. Reload the apps in the UI again.

=============

[frikky]

Hey!

This is a good starting point, and is something we're working on behind the scenes. The major difference here long-term is probably that we're putting Github both at the start and end of the "app release" process. This basically means anything on Github goes into shuffler.io, and anything on shuffler.io goes onto Github.

Right now, we're just doing the former, but focusing on the latter, as it allows people to VERY easily release anything they've built with e.g. OpenAPI. Github is good... if it wasn't for the fact that a LARGE % of our users aren't really contributing, as it's too hard without previous experience.

So what I think is that it would be better to just create this release system on the test version of our site instead, meaning we autodeploy it, and have creators and contributors (like yourself) be a part of that cycle.

In short: testing stuff locally and manually is tedious.

[00willo]

@frikky totally understand. Having a low barrier to entry for inexperienced users to enable them to contribute is awesome.

I was only thinking of being additive to that process. So, ror myself as well, I prefer to do testing like this manually first, rather than having that process wrapped into a UI of a tool. If I understand the fundamentals pieces of what needs to be done, I find that I sometime like to break it down and perform the steps manually. Something like:

1. cd python-apps
2. git pull
3. look over changes to understand what's changed
4. possibly hack in additional debug statements
5. run tests if there are any
6. trigger app to load
7. test in workflow

This way, I'm in control of knowing what the changes are and they're isolated to exactly what I've done to test, not running as part of other actions that might fail and not ending up in the valid state I expect to be in after performing

Would you consider some documentation like this is added in the short term, with appropriate notes mentioning that this is the interim local testing process, and that it'll change in the future?

I'm also just recalling that I haven't finished reading over the contributing documentation. 😄 I think I started following and reading some of the links off that markdown page and got lost in a following link on the next page, and the next. Hahaha