Skip to content
This repository was archived by the owner on Feb 22, 2022. It is now read-only.

Conversation

@BenGalewsky
Copy link
Contributor

Problem

Deployment is cumbersome and error-prone

#Approach
Added a new tag_and_release script that:

  1. Updates the version.py string to match the version
  2. Creates a branch named after the version
  3. Commits and pushes to trigger CI job

@BenGalewsky BenGalewsky assigned ghost Aug 11, 2021
@codecov
Copy link

codecov bot commented Aug 11, 2021

Codecov Report

Merging #245 (12761c6) into main (cdce297) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##             main     #245   +/-   ##
=======================================
  Coverage   63.03%   63.03%           
=======================================
  Files          25       25           
  Lines        1856     1856           
=======================================
  Hits         1170     1170           
  Misses        686      686           

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 cdce297...12761c6. Read the comment docs.

@BenGalewsky
Copy link
Contributor Author

Oops - I see that our convention is to name branches with a leading v (v0.3.2), but that won't work in the VERSION string.

@BenGalewsky
Copy link
Contributor Author

Fixed that and verify that the provided version is a valid SemVer for good measure

Copy link

@ghost ghost 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 reasonable. One gotcha is that the VERSION string in main will likely not be very meaningful if we don't explicitly merge / cherrypick version update commits back to main. One option may be to push the version bump to main before branching the release branch. Or we just get in the habbit of cherry-picking the version bumps back into the main branch.

@BenGalewsky
Copy link
Contributor Author

This looks reasonable. One gotcha is that the VERSION string in main will likely not be very meaningful if we don't explicitly merge / cherrypick version update commits back to main. One option may be to push the version bump to main before branching the release branch. Or we just get in the habbit of cherry-picking the version bumps back into the main branch.

I was thinking that main could just be version 0.3.0 until the next "major" release. We've got to keep the regular deployments as easy as possible otherwise we fall behind

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants