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/Build] setuptools-scm fixes #8900

Merged
merged 1 commit into from
Oct 14, 2024

Conversation

dtrifiro
Copy link
Contributor

@dtrifiro dtrifiro commented Sep 27, 2024

  • expand .dockerignore
  • use COPY . . instructions to copy full repo before building the image (Dockerfile/Dockerfile.openvino). This prevents the repo from being "dirty" in the container build.
  • add setuptools_scm section in pyproject.toml to silence warning
  • get rid of buildkite_commit build arg for release pipelines (replaced with setuptools-scm)
  • install requirements-build.txt as part of build.sh

See #4738 (comment) for context

Copy link

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can do one of these:

  • Add ready label to the PR
  • Enable auto-merge.

🚀

@@ -1,4 +1,31 @@
vllm/*.so
/.venv
/build
dist

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These additions should be safe and should make sure that COPY . . in the Dockerfiles does not copy any additional files that shouldn't go in a build.

I'm unsure on whether there's anything else we might need to add here to avoid copying temporary from the host into the container build (mostly thinking about vllm/vllm_flash_attn right now)

@@ -9,16 +9,7 @@ RUN apt-get update -y && \
ffmpeg libsm6 libxext6 libgl1
WORKDIR /workspace

# copy requirements
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we copy files separately to avoid docker build cache invalidation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a problem? The next step builds vllm, and that relies sccache anyway, which greatly speeds up the process.

- expand .dockerignore
- use `COPY . .` instructions to copy full repo before building the
  image (Dockerfile/Dockerfile.openvino)
- add setuptools_scm section in pyproject.toml to silence warning
- get rid of `buildkite_commit` build arg for release pipelines
  (replaced with setuptools-scm)
- install build requirements in `build.sh`
- fix get_vllm_version in `collect_env.py`
from vllm import __version__, __version_tuple__

if __version__ == "dev":
return "N/A (dev)"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use 1.0.0-dev instead of N/A

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

__version__ will be set to dev only if setuptools-scm doesn't write vllm/_version.py (or something else bad happens with imports, see here, meaning we cannot infer what version this is (.git is not present ).

In this case, I think we have no reason for setting this to 1.0.0-dev, we can just acknowledge that this is an unknown development build.

if __version__ == "dev":
return "N/A (dev)"

if len(__version_tuple__) == 4: # dev build
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this 4 particularly?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can I get some more context on __version_tuple__?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can find the setuptools-scm docs here: https://setuptools-scm.readthedocs.io/en/v8.0.1/usage/

For dev builds, version tuple is going to look like this:

(0, 6, 3, 'dev76', 'g78a09a757')

for exact tags, version tuple is going to look like this:

(0, 6, 3)

i.e. you have an extra field for development builds which includes the git sha

@simon-mo simon-mo merged commit 203ab8f into vllm-project:main Oct 14, 2024
29 checks passed
@simon-mo
Copy link
Collaborator

Testing this out today.

@dtrifiro dtrifiro deleted the setuptools-scm-fixes branch October 15, 2024 13:55
charlifu pushed a commit to charlifu/vllm that referenced this pull request Oct 23, 2024
Signed-off-by: charlifu <charlifu@amd.com>
Alvant pushed a commit to compressa-ai/vllm that referenced this pull request Oct 26, 2024
Signed-off-by: Alvant <alvasian@yandex.ru>
garg-amit pushed a commit to garg-amit/vllm that referenced this pull request Oct 28, 2024
Signed-off-by: Amit Garg <mitgarg17495@gmail.com>
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 this pull request may close these issues.

4 participants