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

Fix version issues in the publish workflow #376

Merged
merged 9 commits into from Jun 26, 2020
Merged

Fix version issues in the publish workflow #376

merged 9 commits into from Jun 26, 2020

Conversation

shyamd
Copy link
Contributor

@shyamd shyamd commented Jun 26, 2020

This fixes the versioning issue in the publish workflow due to having it stored in __init__.py now.

@codecov
Copy link

codecov bot commented Jun 26, 2020

Codecov Report

Merging #376 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #376   +/-   ##
=======================================
  Coverage   90.27%   90.27%           
=======================================
  Files          54       54           
  Lines        2386     2386           
=======================================
  Hits         2154     2154           
  Misses        232      232           
Flag Coverage Δ
#unittests 90.27% <ø> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update de1979e...44d0bab. Read the comment docs.

@shyamd shyamd requested review from ml-evs and CasperWA and removed request for ml-evs June 26, 2020 00:24
Copy link
Member

@ml-evs ml-evs left a comment

Choose a reason for hiding this comment

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

This looks like a sensible fix, just so I have it straight: the versions get updated according to the tag, if the GH release has a semver title, then required all the other files get updated, commited, and the tag gets moved forward, which has to be a force push. Right?

Is there any way we can change the push to git push --force --tags <the_tag_in_question> instead of just git push --force (if that is what is actually happening)? I must admit all these 3rd party actions make it quite hard to follow without digging into them...

@shyamd
Copy link
Contributor Author

shyamd commented Jun 26, 2020

Yeah, it already did that. This fix addresses:

  1. The fact that the publish workflow wasn't actually committing the file that had the version change.
  2. Ensures the tag for the release moves forward to the commit we push. This keeps the tagged commit and the release on pypi consistent.

Edit:
The push both takes care of the commit and the tag. We might not need the force, which I'm testing next.

@ml-evs
Copy link
Member

ml-evs commented Jun 26, 2020

The push both takes care of the commit and the tag. We might not need the force, which I'm testing next.

Gotcha, tag me when you're done and I can review when I wake up.

I stuck a related Q about building wheels on slack

@shyamd shyamd requested a review from ml-evs June 26, 2020 01:31
Copy link
Member

@ml-evs ml-evs left a comment

Choose a reason for hiding this comment

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

This LGTM now, I'm sure we'll be doing another release soon so we can test it. I'll give @CasperWA a chance to look too.

@shyamd shyamd merged commit cb088b5 into Materials-Consortia:master Jun 26, 2020
@shyamd shyamd deleted the fix-publish-openapi branch June 26, 2020 13:38
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.

None yet

2 participants