-
Notifications
You must be signed in to change notification settings - Fork 298
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] Push circt python wheel to pypi nightly #5412
[CI] Push circt python wheel to pypi nightly #5412
Conversation
afed1d7
to
a7b372c
Compare
.github/workflows/uploadWheels.yml
Outdated
with: | ||
path: ./wheelhouse/*.whl | ||
retention-days: 7 | ||
|
||
- name: Upload wheels (Tag) | ||
- name: Upload wheels (Non-Tag and Nightly) | ||
uses: pypa/gh-action-pypi-publish@release/v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikeurbach @teqdruid how do we version this to be made into a dev release on pypi?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the versioning works like the pycde versioning scheme, breaking it out isn't necessary. The versioning lib automatically detects the most recent tag in the commit's history. If the commit is the tag, it uses that. If not, it appends .dev<numberOfCommitsSinceTag>
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you really just need the schedule addition above. Am I correct @mikeurbach ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do use setuptools_scm, so the versioning should work as expected. But I think it makes sense to have three steps:
- one for when there is a tag (which is run on the release event trigger) and uploads the tag version to PyPI
- one for when the event is the cron, which uploads the dev version to PyPI
- one for anything else (useful for testing the workflow), which uploads artifacts to the job for inspection
I think it would make sense to use:
- name: Upload wheels (Tag)
if: github.ref_type == 'tag'
- name: Upload wheels (Nightly)
if: github.event_name == 'cron'
- name: Upload wheels (Workflow Dispatch)
if: github.ref_type != 'tag' && github.event_name != 'cron'
What do you think @teqdruid @rsetaluri ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would be the actions? My point is, how would they differ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I see, yes we can combine the steps that push to pypi, something like:
- name: Upload wheels (Tag or Nightly)
if: github.ref_type == 'tag' || github.event_name == 'cron'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah. I was assuming that you'd also want to push to pypi on a workflow_dispatch, but perhaps not...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think we should only push to pypi on automated builds. If someone is testing the workflow itself or something, I don't think we need to push new versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree with the two modes. In the case of !(tag || cron)
, we can just download artifacts from github actions
No description provided.