Updated workstation release docs for Debian packages: #46
Conversation
zenmonkeykstop
force-pushed
the
update-sdb-deb-section
branch
2 times, most recently
from
6bd0262
to
be8bada
Compare
- Documented workflow for releases from a dedicated release branch - Clarified process for applying bugfixes - Clarified steps for managing application and debian changelogs and versions - Updated commands to reflect changes in freedomofpress/securedrop-builder#427
zenmonkeykstop
force-pushed
the
update-sdb-deb-section
branch
from
be8bada
to
dee5226
Compare
| 2. Push a changelog commit. | ||
| 3. Push an rc tag in the format ``<major>.<minor>.<patch>~rcN`` on your new commit. We will be building from this tag in the next step. | ||
| 1. Create a release branch (eg. ``release/1.2.3``) in the repo of the component you want to release. | ||
| 2. Update the component version to the intended release version (not the RC!) using the ``update_version.sh`` script. |
There was a problem hiding this comment.
I don't think we should be doing this, the version should match the package version, aka 1.2.3-rcX. The only reason we can get away with this right now is because the d/changelog is in a separate repo, but we're going to fix that (c.f. freedomofpress/securedrop-builder#308).
Bigger picture, I think this is coming from a desire eliminate the need to change the component repo, but using an arguably incorrect version number IMO goes too far and pushes us into confusing rather than helpful. We should prioritize being comfortable with diffing packages so we can verify the changes being made are what we want instead of avoiding making changes. (And we're going to lose this ability when debian/ moves into the component repo anyways, so optimizing for it doesn't make sense)
| 3. Push an rc tag in the format ``<major>.<minor>.<patch>~rcN`` on your new commit. We will be building from this tag in the next step. | ||
| 1. Create a release branch (eg. ``release/1.2.3``) in the repo of the component you want to release. | ||
| 2. Update the component version to the intended release version (not the RC!) using the ``update_version.sh`` script. | ||
| 3. Update the changelog to include changes since the last release. |
There was a problem hiding this comment.
Clarify whether this is changelog.md or debian/changelog.
|
|
||
| .. code-block:: sh | ||
|
|
||
| git clone git@github.com:freedomofpress/securedrop-builder.git | ||
| cd securedrop-builder | ||
| make install-deps # This also confifgures the git-lfs repo used to store SecureDrop Workstation dependencies | ||
|
|
||
| 3. Create a Debian changelog entry for the new version of the package you are about to build. | ||
| 4. Create a Debian changelog entry for the new version of the package you are about to build, using the format ``x.y.z~rcN`` - note the ``~``, as this differs from the git tag format. |
There was a problem hiding this comment.
The script takes care of the s/-/~/g now, so I think we can keep the documentation simple and have humans only input the version in one format and let scripts munge it as needed.
|
|
||
| Step 2: Build and deploy the package to ``apt-test`` | ||
| ---------------------------------------------------- | ||
|
|
||
| 1. Open a terminal in your named DispVM called ``sd-dev-dvm`` (see :ref:`How to create the DispVM for building packages`). | ||
| 1. Open a terminal in your ``sd-dev-dvm`` builder DispVM (see :ref:`How to create the DispVM for building packages`), and prepare to record terminal output- either by using a utility like ``script``, or just by making sure you have infinite scrollback enabled to allow for cut/pasting later. | ||
| 2. Clone the the ``build-logs`` and ``securedrop-apt-test`` repos. |
There was a problem hiding this comment.
Does this need to be done in the dispVM?
Status
Work in progress
Description of Changes
Fixes #43
Testing
Release
Should be merged after freedomofpress/securedrop-builder#427.
Checklist (Optional)
make docs-lint) passed locallymake docs-linkcheck) passedmake docs) docs at http://localhost:8000