test: add integration testing for OVAL

[awilson-urbane]

If this Pull Request is work in progress, Add a prefix of “[WIP]” in the title.

What did you implement:

• Automated integration testing for feed consumers and Postgres DB
  • Runs on push and Sunday at midnight
  • run locally with make test-integration

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Wrote integration tests. Clone repo and run make test-integration, or see GH actions.

Checklist:

You don't have to satisfy all of the following.

• Write tests
• Write documentation
• Check that there aren't other open pull requests for the same issue/feature
• Format your source code by make fmt
• Pass the test by make test
• Provide verification config / commands
• Enable "Allow edits from maintainers" for this PR
• Update the messages below

Is this ready for review?: YES

Reference

[eyablokov]

It would be nice to see it merged into the upstream, since I face this issue as well.

[JulianNeuhaus27]

Similar issue like this: vulsio/go-kev#43

[eyablokov]

@awilson-urbane , is it ready to be merged to the upstream?

[awilson-urbane]

@eyablokov Yes, this is ready. I just tested again (make test-integration) and updated the Fedora part to point to currently-supported versions

[eyablokov]

@awilson-urbane , @JulianNeuhaus27 is okay with this PR. He checked it out earlier :)

[awilson-urbane]

What are next steps? Who has permission to merge the PR?
(sorry for the confusion - I've not contributed to this project before)

[eyablokov]

As far as I understand, @MaineK00n or @kotakanbe should do that.

[MaineK00n]

I have been aware of this PR for some time, but I wonder if it is necessary to add an integration test to a fix that only changes the GORM type.

[MaineK00n]

If integration tests are also included in the merge, for example, it is recommended that the merge be periodically checked not only for PostgreSQL but also for MySQL, SQLite3, Redis, and so on.

[MaineK00n]

@awilson-urbane

I have changed the PR to one that guarantees the success of periodic fetches for each DB Type.

The following points need to be considered and modified.

• Periodic fetch success should be guaranteed not only for PostgreSQL but also for MySQL, SQLite3, and Redis.
• Containerization of goval-dictionary is not necessary, and it would be better to prepare only the DB part in a container or the like as appropriate (is docker-compose necessary?). I think you can do what you want by just preparing a temporary DB like fetch-redis and running it on a schedule with GitHub Actions.
• I would avoid the name Integration if the content only guarantees fetch.

[MaineK00n]

#274 (comment)

[awilson-urbane]

Hi @MaineK00n, thank you for your guidance, and I apologize for the lapse in communication. I'm revisiting this now and I'll have the requested changes ready for your review ASAP.

[awilson-urbane]

OK @MaineK00n I've set up fetch testing for Postgres, Sqlite, MySQL and Redis. I also removed docker-compose from the process.

Here are the results from a test run: https://github.com/awilson-urbane/goval-dictionary/actions/runs/4198013433

[eyablokov]

By the way, @awilson-urbane , is there any Docker image of your branch existing and publicly available? Docker Hub etc.

[awilson-urbane]

Hi @eyablokov, No, I haven't published the image anywhere.

[MaineK00n]

Basically, I don't want to assume that this fetch is going to run on hand. Therefore, we would like to pay attention to the execution time of GitHub Actions.

As far as I can tell from your test, it took about 14 minutes.
I would like to reduce this test time as much as possible.
Do you know of any good ways to do this?
https://github.com/awilson-urbane/goval-dictionary/actions/runs/4198013433

[awilson-urbane]

We could reduce the overall CI time by changing the conditions under which it runs (just weekly instead of weekly and on push), but I don't know how to make the fetches themselves run faster.

[eyablokov]

@MaineK00n , is this bug fix in the latest tagged image here? I would like to see 0.8.2 version.

[MaineK00n]

@eyablokov
I will create v0.8.2 soon, but until then, please use the latest tagged image.