Skip to content

Automate tarball builds #195

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

Closed
eloquence opened this issue Sep 9, 2020 · 2 comments
Closed

Automate tarball builds #195

eloquence opened this issue Sep 9, 2020 · 2 comments

Comments

@eloquence
Copy link
Member

eloquence commented Sep 9, 2020

We currently manually build and upload tarballs as part of the release process. Per this repo’s README:

  1. Build tarballs, and create a detached signature with the release key

This involves two people at a minimum: one person to prepare the PR, and another to review it. As of #185, tarballs are reproducible. This means we can safely automate the creation of tarballs via a buildbot. The bot would open a PR (from a fork or branch) with the tarball artifact.

A person with signing authority would verify the build locally and push a commit with a detached signature, then merge it, reducing the number of people involved to 1.

This issue should be considered blocked on #147 to prevent accidental merges of unsigned artifacts by a reviewer.

In scope of this issue

  • Investigate implementation options for a buildbot that opens PRs (cf. previous efforts such as @redshiftzero's backport bot)
  • Implement a buildbot that creates tarballs and opens PRs into this repo as soon as a release tag is pushed to a SecureDrop Workstation project repo.
  • Update the procedures in this repo’s README
@eloquence
Copy link
Member Author

Depending on the implementation strategy, this issue may result in changes in other repos. It may also be worth considering the benefits of tooling beyond our primary toolchain; e.g., does Codefresh give us options here that CircleCI does not?

@eloquence
Copy link
Member Author

We discussed this further in today's tech meeting. I'm provisionally closing this issue in favor of a clearer focus on going straight for an experimental reproducible & automated .deb build. The main rationale is that the team is leaning towards removing the tarballs/ directory from this repo. #185 added tooling for significantly simplifying the tarball build step, so the benefit to ourselves of keeping the tarballs around is very limited, while the benefit for third parties (e.g., researchers) also seems limited, given that there are other ways to obtain a specific version of a package, such as the GitHub auto-generated tarballs: https://github.com/freedomofpress/securedrop-client/tags

If we decide that we want to preserve the tarballs/ step, we can reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant