-
Notifications
You must be signed in to change notification settings - Fork 70
Make release #1059
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
Make release #1059
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1059 +/- ##
=========================================
- Coverage 90.85% 88.8% -2.05%
=========================================
Files 164 165 +1
Lines 6146 6433 +287
=========================================
+ Hits 5584 5713 +129
- Misses 562 720 +158
Continue to review full report at Codecov.
|
Makefile
Outdated
python setup.py sdist; \ | ||
pip install dist/starfish-$$VERSION.tar.gz | ||
|
||
release-verify: release-check slow |
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.
This doesn't install your to-be-released version, right? So this is checking source against the notebooks? Would it be preferable to use the environment prepped in release-prep
and run it there?
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.
Prep does. At the moment, it's very much setup to use the three in order. prep
and verify
can be combined if you'd prefer.
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.
Would it make sense to make release-verify
explicitly depend on release-prep
then?
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.
Happy either way. If everyone prefers, maybe it's just release-build
and release-publish
.
Makefile
Outdated
@VERSION=$(shell sh -c "git describe --exact") && \ | ||
printf '\n# Please execute the following steps\n';\ | ||
echo git push origin $$VERSION; \ | ||
echo docker push $(DOCKER_IMAGE); \ |
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.
Who owns the docker image rights? I presume not everyone can just push it?
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.
At the moment, I do. Unfortunately, it can't be synced with github teams. I'll pass over to whomever. Can you confirm that you are also @ttung
on Docker Hub?
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.
I don't know. :)
Once this lands, I think it would make sense to distribute it to everyone who regularly commits here (yourself, me, @ambrosejcarr, @shanaxel42, @kne42)
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.
I am ambrosejcarr on dockerhub.
[metadata] | ||
name = starfish | ||
summary = Pipelines and pipeline components for the analysis of image-based transcriptomics data | ||
author = Deep Ganguli |
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.
I guess we should fix this at some time to include more peeps. :)
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.
Definitely leaving that up to someone else 😄
With the above, you should be able to do:
cc: @shanaxel42 @ttung @ambrosejcarr (and yes, once the dust settles, this could become |
Preparation steps:
Also:
Your repository should be auto-created when you push to Docker Hub, though you can pre-create it if you want. Then:
Updated on Mar. 13:
Finally:
Skipping
So running those commands in my case:
The suffix
See results under: |
@ttung @shanaxel42 @ambrosejcarr et al: if you create https://test.pypi.org/account/register/ accounts, I'll add you to the starfish project. Note that even on test.pypi you can never upload a given version more than once (even if you delete it). For testing, you might use |
I'm ambrosejcarr on test 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.
this looks super cool. can't wait to try it out. please see the comments.
So I'm clear: you'd prefer to try it on |
The directions are not very clear (and I guess it can be clarified), but I assumed it had to be run from master. |
Happy to expand the testing instructions in #1059 (comment) but I assume that you can work from this branch under the assumption that we're pushing to all the testing versions of remote resources:
|
Added |
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.
I had to rebase and update master locally, but I think this is good to go.
# | ||
# (0) Check out the latest version of the branch for releasing. | ||
# | ||
# (1) `make release-changelog` to print a suggested update to |
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.
hilariously, make release-changelog > CHANGELOG.md
does horrible things...
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.
Heh, yeah. Likely the only option there would be to create a temp file and overwrite, not printing anything to standard out.
Alright, merging then after a minor wording change. Looking forward to seeing this in action. 😉 |
close #761
Release make targets using versioneer for automatically bumping the version number. The general strategy is that once all PRs/commits have been merged, a tag is created locally using
git
. After that someone "preps", "verifies", and then "uploads" (names open for discussion).The version numbers from versioneer currently follow PEP 440 (though a number of alternatives are available). All non-release tags include a suffix beginning with
+
:This PR does not try to:
Other minor points worth noting:
run_notebooks
torun-notebooks
(This looks to be untested)versioneer
might be in ordermake clean
target__is_release_tag__
is still a string