Securise app version and upgrade validate_app

[LiquidITGuy]

First of all, thank you for your contribution! 😄

Hi,
I tried to standardize the $$cap_app_name to check and to fix all the fixed versions without variables and with fixed values.

I added three checks on validate app :

• does the app version exist
• is this variable different than latest
• does the description give a way to know the available tags
  I also use a for of instead of the var i for performance purpose.

To finish I would later create a new command to know which packages are deprecated and from how long

I think this PR is more readable commit by commit.
I hope this could help

Regards

• I have tested the template using the method described in README.md thoroughly
• I have ensured that I put as much default values as possible (except passwords) to ensure minimum effort required for end users to get started.
• I have ensured that I am not using the "latest" tag as this tag is dynamically changing and might break the one-click app. Use a fixed version.
• I have made sure that instructions.start and instructions.end are clear and self-explanatory.
• I've executed the checks if necessary by running npm ci && npm run validate_apps && npm run formatter (If failling run the prettier: npm run formatter-write)
• I will take responsibility addressing any issues that arises as a result of this PR (maintaining this app).

[LiquidITGuy]

The failed check is an unvolontary proof of concept of the new validation 😄

[githubsaturn]

Thanks for the PR! It was a bit too scary to look at and it took some time for me to fully review this.

I tried to standardize the $$cap_app_name to check and to fix all the fixed versions without variables and with fixed values.

I believe you're referring to version, not cap_app_name, right?

While I see value in this, I think this becomes a maintenance hurdle moving forward. One simple case for example is that there are cases where there are multiple versions in the same One Click App. You can only validate one of them, which one?

does the app version exist

You're just checking for the variable to exist, not the actual version on dockerhub, right?

does the description give a way to know the available tags

Again, this is just relying on the existence of the word "tag" and some other words... I don't see this as the right way to do this.

Overall, this seems like it is targeting the right goal, but the implementation is not ideal.
Of all the changes that are introduced in this PR, I think a valuable one is an extension to one of them. You can part the file and find all variables (check anything that starts with $$). Then, make sure it is a variable that is defined in the variables section of the file. Feel free to open another PR if you are open to making that validation.

[githubsaturn]

To finish I would later create a new command to know which packages are deprecated and from how long

How did you plan on doing this?

[LiquidITGuy]

I tried to standardize the $$cap_app_name to check and to fix all the fixed versions without variables and with fixed values.
I believe you're referring to version, not cap_app_name, right?

exactly

While I see value in this, I think this becomes a maintenance hurdle moving forward. One simple case for example is that there are cases where there are multiple versions in the same One Click App. You can only validate one of them, which one?

it is the main caprover app version

Again, this is just relying on the existence of the word "tag" and some other words... I don't see this as the right way to do this.

With standardize the name of the caproverappVersion

To finish I would later create a new command to know which packages are deprecated and from how long
How did you plan on doing this?

With a script who are fetching the docker image and check if latest have the same hash (or date) than the default version

[LiquidITGuy]

and I will try to integrate this change too