-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Add release GitHub actions #336
base: master
Are you sure you want to change the base?
Conversation
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.
LGTM
b54aca6
to
f0bed51
Compare
…ing its parameter name rather than a fixed index
d3c6da1
to
2ea3c9a
Compare
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.
Great! Looking good with one question.
May be nice to also add some instructions on creating a release for maintainers so they know to tag the release in the right way.
# Per #389, set this to the currently released version by default | ||
param_names = [p.name for p in f.params] | ||
checkout_index = param_names.index("checkout") | ||
f.params[checkout_index].default = __version__ |
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.
It looks like some places (like the release tags), we use vX.Y.Z
and others we use X.Y.Z
. We should check if we need the v
prefix here or not.
closes #317
closes #389
Add GitHub actions to publish on release
Do not merge - #315 is needed first. After transfer, the repo should automatically have access to the PyPI secrets needed byrelease.yml
ccds.__version__
Users can now see the version of
ccds
after importing (ccds.__version__
). However, the project name is different than the module name. This means that inversion.py
, we have to hard code the project name with:Instead of using:
Using release version as default tag for checkout
Per #389, we wanted a way to allow more stable behavior when someone installs ccds. Currently, any change to the template on the master branch will automatically get propagated when someone runs ccds (unless the person has downloaded the template already and opts to skip that step). As part of this PR, we now default to ccds checking out the tag associated with the installed ccds version.
Users can always get the latest by checking out the master branch (
-c master
) or updating ccds.Docs
This PR does not include versioning for docs (eg. with a "Build docs" job). That is tracked separately in #334