-
Notifications
You must be signed in to change notification settings - Fork 2
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
Implement git tag checking for autoupdate. #43
base: sensotrend-uploader
Are you sure you want to change the base?
Conversation
For release: - The **/package.json version field must be updated first to contain correct version number and channel suffix (alpha, beta, release). - A tag must be created with same values for the release commit, e.g. git tag -a -m "" 1.2.3-alpha - Various packaging commands can be issued. Resulting release/$channel-$os.yml file and executable must be copied to update server. For snapshot builds: - The **/package.json version field must be updated to contain "snapshot" as the channel suffix. - Various packaging commands can be issued. The package.json version is compared against tag name so they must match.
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.
A tag must be created with same values for the release commit,
e.g. git tag -a -m "" 1.2.3-alpha
Any way to automate this? That is, to get the version number and channel from the package.json, for instance?
Just thinking of avoiding possible typos...
Gather the version, name, description and other information from git describe.
Yes, now in a279e3c. Just the reverse, though, as version information in package.json is outdated in conflicting manner due parallel development that keeping it there is not a good option. So, the version is not determined automatically depending on where the previous tag exists. If current commit doesn't have a tag, it must be a development run or snapshot build. And if current commit is tagged, it must be a build aimed for release that is declared by the tag. (If running development build in a tagged commit, it should not matter that the run/build is marked by the tag. Only thing is, that the version is not currently marked dirty if there are local uncommitted changes on a tagged commit.) |
By this, each server address is defined only once and does not require manual tuning depending on whether the build is meant for development, testing or production. Also the default server group can be changed with a single variable rather than requiring to supply them all. Additionally, the change does not pollute the pre-defined server groups. Build-time environment variables: - ENVIRONMENT configures which environment updates are checked from and which server URL group is used by default. - DEFAULT_ENVIRONMENT changes the default server URL group from what is configured by definition set by ENVIRONMENT (or default). Run-time environment variables: - UPLOADER_ENVIRONMENT changes the default server URL group from what would be used by default (defined in build-time by above variables). - API_URL et co change the value from what would be used by the server URL group. If any of these are set, a Custom entry will be added to server selection menu.
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.
Good stuff!
I'm a bit concerned over how we'll try to get these changes adopted upstream (in Tidepool's repo). Probably one change at a time (environment management and tagged versions separately)? But we can worry about that later on.
@jlaunonen will you present this in practice in a demo session?
For release:
correct version number and channel suffix (alpha, beta, release).
e.g. git tag -a -m "" 1.2.3-alpha
release/$channel-$os.yml file and executable must be copied to update
server.
For snapshot builds:
"snapshot" as the channel suffix.
The package.json version is compared against tag name so they must
match.