Support the Download of Configuration Files from a Remote Location Through HTTP

[astutesource]

Support the Download of Configuration Files from a Remote Location Through HTTP

[gkapfham]

Hi @simojo, I see that you are assigned to this issue. Can you please give us a status update? Is this a feature that you might be able to implement and have ready by the end of the next sprint?

If you are going to work on this feature, I encourage you to check-in with the senior software engineer on our team who can advise you on where to integrate your code. You should also chat with our QA engineer because we need to ensure that your code has high test coverage and that we can have a suitable confidence in its correctness.

Finally, if you could implement this feature then we should definitely talk about integrating it into other tools like gatorgrade. It would be really helpful to have a remote-download feature for configuration files!

[simojo]

@gkapfham I am currently still working on this, mostly because I haven't devoted time to it yet. Currently trying to test URL validation and writing a test case accordingly. Hypothesis has a fuzzing strategy where you can include randomly generated URLs, but this appears to be a test feature, so it could be potentially volatile to include in our tool. https://hypothesis.readthedocs.io/en/latest/data.html#hypothesis.provisional.urls

What do we think of using Hypothesis's provisional URL strategy in a unit test?

[simojo]

@gkapfham I have an additional question for you regarding how chasten reads configuration files. This is not obvious to me, so I figured it was appropriate to ask you: If we were to attempt to pull a remote configuration by including https://raw.githubusercontent.com/AstuteSource/chasten-configuration/master/config.yml as the input config file, I'm now seeing that every config.yml is going to reference local files. Do you have any recommended strategies for inputting remote configuration files? Should we allow the specification of checks in the main config.yml file? I'm having a hard time deciding what design choices here would be appropriate, because it seems that I'm going to have to modify an existing feature.

[simojo]

I have decided that the above comment no longer needs to be addressed. The design I am implementing now will allow the following rules:

• --config may be Union[Path, URL] (URL provided by purl library)
• If config.yml is a Path, the checks-files yaml values may either be Path or URL objects.
• If config.yml is a URL, the checks-files yaml values may be only URL objects.

Does anyone else have any opinions on this?

[gkapfham]

Hello @simojo, yes, what you have described sounds like a very good idea! Thanks for pushing forward this issue, I think that it will be a great contribution to the tool.