Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CI] OpenSearch Dashboards specific docker image #4032

Open
kavilla opened this issue May 15, 2023 · 0 comments
Open

[CI] OpenSearch Dashboards specific docker image #4032

kavilla opened this issue May 15, 2023 · 0 comments
Labels
ci enhancement New feature or request

Comments

@kavilla
Copy link
Member

kavilla commented May 15, 2023

Is your feature request related to a problem? Please describe.

Origin: #3997

The CI utilizes the official test runner images published by GitHub. The problem here is that GitHub runners get updated frequently with dependencies that prevent our application from starting without us doing extra steps, due to the nature of the project being able to support multiple versions and avoid backwards incompatibility.

We also do not actively track releases and sometimes the release notes for the github runner images are not updated to accurately reflect the actual versions in the runners. This causes errors in our CI that we were not expecting and causes blockers on PRs until we allocate resources to fix the CI problems.

Describe the solution you'd like

Utilizing our Dockerfile we create a GitHub specific Dockerfile and publish an image potentially with a generic entrypoint to install dependencies. But ideally a static Dockerfile that limits the amount of random issues to address for example, we do not have to worry about the chrome version changing.

We can also reduce the runtime of our CI by reducing the setup steps. The CI runs through setup steps like setting up yarn and NVM. This could be just be built into the Docker image and then ensure the GitHub user code 1001 has access to these folders so that these setup steps can just be skipped.

However, we will have to maintain this Docker image which is another responsibility but since we maintain it then we do not have to worry about an upstream resource breaking our CI. We should also consider having an un-official docker hub to have full control on this image.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant