OpenLiberty / OpenLiberty/ci.docker
Add tests to verify InstantOn support against produced liberty images
Nobody has claimed this yet.
- Dominant language
- Shell
- Stars
- 48
- Forks
- 60
- Avg merge
- 3h 2m
- Merged PRs (30d)
- 3
Description
We need ongoing automated tests against the liberty container images that get produced that verify basic InstantOn functionality is working. This could expand to a wide set of tests, but initially this issue is about establishing basic tests to verify InstantOn is working property in an automated way against images produced by this repository for UBI based images.
(2023/08/01) Further refinement of the requirements based on initial discussions:
Add some level of liberty container image verification early in dev process. As far as we know, none currently exists. Leverage one-pipeline flow to do basic image verification. Basic verification might entail starting/stopping server with some basic application load. Target weekly builds and maybe even nightly builds of liberty and open-liberty.
More long term need capability to drive this container build/verification from an openliberty pull request.
In addition to the basic verification, add basic instantOn verification tests with checkpoint/restore on same VM type.
Longer range, we need cross-VM checkpoint, restore, i.e. tests where the checkpoint image build and the restore happen on diffent types of VM's.
Public cloud/kubernetes testing are still province of SVT.
Need to pull CI/CD into further discussions since they own majority of this process.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the one-pipeline flow that produces UBI-based Liberty container images and identify where automated verification can run. Define basic server start/stop and application-load checks, then add InstantOn checkpoint/restore coverage on the same VM type. Done means the checks run against produced images in weekly or nightly builds; cross-VM and pull-request-driven testing are longer-term requirements.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, shell
- Domain
- ci-cd, devops, testing-qa
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100