You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, a GitHub action to push ExplainaBoard to PyPI is triggered on push commit to main if some change is maded in version.py (regardless of version change). This approach is not reliable because it is possible to add comments or more code to version.py. In fact, #415 added docstrng to version.py which accidentally triggered the CI, and CI failed because the version didn't change.
It is better to configure the CI not to get triggered accidentally. For example, it is possible to trigger the CI on pushing a tag (e.g., v0.12) to this repository rather than on pushing a commit to main. (NOTE: Whether to create release branches or not is a separate topic). Process to bump the version in version.py, and push tags need to be automated to avoid mistakes.
The text was updated successfully, but these errors were encountered:
This sounds good to me, as long as we can realize the following:
Process to bump the version in version.py, and push tags need to be automated to avoid .
One reason why this is automated now (instead of using tags) is that in my previous experience I used tags for releases but it was error prone to need to update the code and the tag manually, and one was often forgotten.
Some techniques used by other libraries is autogenerating version information from the tag: refers the tag string, and if it is formed as a version number, copy it to _version.py and publish the library with it.
There is a tool to refer information in the version control system during setup, which is used in other projects (e.g., Black)
Currently, a GitHub action to push ExplainaBoard to PyPI is triggered on push commit to
main
if some change is maded inversion.py
(regardless of version change). This approach is not reliable because it is possible to add comments or more code toversion.py
. In fact, #415 added docstrng toversion.py
which accidentally triggered the CI, and CI failed because the version didn't change.It is better to configure the CI not to get triggered accidentally. For example, it is possible to trigger the CI on pushing a tag (e.g., v0.12) to this repository rather than on pushing a commit to
main
. (NOTE: Whether to create release branches or not is a separate topic). Process to bump the version inversion.py
, and push tags need to be automated to avoid mistakes.The text was updated successfully, but these errors were encountered: