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

bug: CI functionality test needs to build latest docker image #112

Closed
Shaoting-Feng opened this issue Feb 12, 2025 · 7 comments · Fixed by #137
Closed

bug: CI functionality test needs to build latest docker image #112

Shaoting-Feng opened this issue Feb 12, 2025 · 7 comments · Fixed by #137

Comments

@Shaoting-Feng
Copy link
Collaborator

Describe the bug

CI functionality test pipeline currently uses remote router image. If some contributors change the codes with the router, the functionality test will not be able to detect whether there is an error or not.

To Reproduce

None

Expected behavior

No response

Additional context

The functionality test should build router docker image as an initial step.

@Shaoting-Feng Shaoting-Feng added bug Something isn't working and removed bug Something isn't working labels Feb 12, 2025
@gaocegege
Copy link
Collaborator

Currently, our Docker image action repushes the image with the same tag if the router version in setup.py remains unchanged, which is not a common practice, The versioned image should be immutable.

https://github.com/vllm-project/production-stack/blob/main/.github/workflows/router-docker-release.yml#L45

I suggest using the Git commit as the tag for the pull request, and only incrementing the version during the release process.

We could build the image using the Git commit, run the action initially, and then proceed with the end-to-end tests.

@Shaoting-Feng
Copy link
Collaborator Author

I am thinking for pull requests and commits, we can build the router image and push it to a port on the local GitHub runner machine instead of pushing it to the GitHub repository. The workflow can then pull the Docker image from localhost. This approach avoids saving potentially wrong image on github.

@Shaoting-Feng
Copy link
Collaborator Author

For your quotes, if we only run this Docker release pipeline when merging into the main branch, it means the PR has already passed the CI pipelines. Using this router as the "latest" image allows users to try the new features without bugs.

@gaocegege
Copy link
Collaborator

"Latest" works for me, but my main concern is about the versioned image. It goes against the expectation that the version is pinned.

@gaocegege
Copy link
Collaborator

I am thinking for pull requests and commits, we can build the router image and push it to a port on the local GitHub runner machine instead of pushing it to the GitHub repository. The workflow can then pull the Docker image from localhost. This approach avoids saving potentially wrong image on github.

Maybe we could use artifacts. https://docs.docker.com/build/ci/github-actions/share-image-jobs/

@Shaoting-Feng
Copy link
Collaborator Author

"Latest" works for me, but my main concern is about the versioned image. It goes against the expectation that the version is pinned.

I agree. We should update the current "build router image" pipeline.

@Shaoting-Feng
Copy link
Collaborator Author

I am thinking for pull requests and commits, we can build the router image and push it to a port on the local GitHub runner machine instead of pushing it to the GitHub repository. The workflow can then pull the Docker image from localhost. This approach avoids saving potentially wrong image on github.

Maybe we could use artifacts. https://docs.docker.com/build/ci/github-actions/share-image-jobs/

Thanks. However, I'm not sure if Minikube can pull images from Artifacts.

I've tested using the local Docker registry, and it works locally. I'll update the "Functionality Test" pipeline accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants