|
|
|
|
#!/bin/bash
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
# Setup - creates the local repo which will be mirrored up to S3, then back-fill it. Your
|
|
|
|
|
# future deploys will eliminate all old versions without these backfill steps:
|
|
|
|
|
# aptly repo create signal-desktop
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
# aptly mirror create -ignore-signatures backfill-mirror https://updates.signal.org/desktop/apt xenial
|
|
|
|
|
# aptly mirror update -ignore-signatures backfill-mirror
|
|
|
|
|
# aptly repo import backfill-mirror signal-desktop signal-desktop signal-desktop-beta
|
|
|
|
|
# aptly repo show -with-packages signal-desktop
|
|
|
|
|
#
|
|
|
|
|
# First run on a machine - uncomment the first set of 'aptly publish snapshot' commands,
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
# comment the other two. Sets up the two publish channels, one local, one to S3.
|
|
|
|
|
#
|
|
|
|
|
# Testing - comment out the lines with s3:$ENDPOINT to publish only locally. To eliminate
|
|
|
|
|
# effects of testing, remove package from repo, then move back to old snapshot:
|
|
|
|
|
# aptly repo remove signal-desktop signal-desktop_1.0.35_amd64
|
|
|
|
|
# aptly publish switch -gpg-key=57F6FB06 xenial signal-desktop_v1.0.34
|
|
|
|
|
#
|
|
|
|
|
# Pruning package set - we generally want 2-3 versions of each stream available,
|
|
|
|
|
# production and beta. You can remove old packages like this:
|
|
|
|
|
# aptly repo show -with-packages signal-desktop
|
|
|
|
|
# aptly repo remove signal-desktop signal-desktop_1.0.34_amd64
|
|
|
|
|
#
|
|
|
|
|
# Release:
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
# NAME=signal-desktop(-beta) VERSION=X.X.X ./aptly.sh
|
|
|
|
|
|
|
|
|
|
echo "Releasing $NAME build version $VERSION"
|
|
|
|
|
|
|
|
|
|
REPO=signal-desktop
|
|
|
|
|
CURRENT=artful
|
|
|
|
|
PREVIOUS=xenial
|
|
|
|
|
ENDPOINT=signal-desktop-apt # Matches endpoint name in .aptly.conf
|
|
|
|
|
SNAPSHOT=signal-desktop_v$VERSION
|
|
|
|
|
GPG_KEYID=57F6FB06
|
|
|
|
|
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
aptly repo add $REPO release/$NAME\_$VERSION\_*.deb
|
|
|
|
|
aptly snapshot create $SNAPSHOT from repo $REPO
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
|
|
|
|
|
# run these only on first release to a given repo from a given machine. the first set is
|
|
|
|
|
# for local testing, the second set is to set up the production server.
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
# https://www.aptly.info/doc/aptly/publish/snapshot/
|
|
|
|
|
# aptly publish snapshot -gpg-key=$GPG_KEYID -distribution=$CURRENT $SNAPSHOT
|
|
|
|
|
# aptly publish snapshot -gpg-key=$GPG_KEYID -distribution=$PREVIOUS $SNAPSHOT
|
|
|
|
|
# aptly publish snapshot -gpg-key=$GPG_KEYID -distribution=$CURRENT -config=.aptly.conf $SNAPSHOT s3:$ENDPOINT:
|
|
|
|
|
# aptly publish snapshot -gpg-key=$GPG_KEYID -distribution=$PREVIOUS -config=.aptly.conf $SNAPSHOT s3:$ENDPOINT:
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
8 years ago
|
|
|
|
|
|
|
|
# these update already-published repos, run every time after that
|
|
|
|
|
# https://www.aptly.info/doc/aptly/publish/switch/
|
|
|
|
|
aptly publish switch -gpg-key=$GPG_KEYID $CURRENT $SNAPSHOT
|
|
|
|
|
aptly publish switch -gpg-key=$GPG_KEYID $PREVIOUS $SNAPSHOT
|
|
|
|
|
aptly publish switch -gpg-key=$GPG_KEYID -config=.aptly.conf $CURRENT s3:$ENDPOINT: $SNAPSHOT
|
|
|
|
|
aptly publish switch -gpg-key=$GPG_KEYID -config=.aptly.conf $PREVIOUS s3:$ENDPOINT: $SNAPSHOT
|
|
|
|
|
|
