ci/cd: publish binaries onto a release when we create a tag #1879
Assignees
Labels
Comments
|
See https://github.com/bassosimone/simulate-ooni-releases for prototype. |
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 22, 2021
This is the miniooni related part of ooni/probe#1879. This diff will require backport to the release/3.11 branch.
3 tasks
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 22, 2021
This is the miniooni related part of ooni/probe#1879. This diff will require backport to the release/3.11 branch.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 22, 2021
This diff backports 7f0fb5e. Original commit message: - - - This is the miniooni related part of ooni/probe#1879. This diff will require backport to the release/3.11 branch. Conflicts: .github/workflows/miniooni.yml
3 tasks
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 22, 2021
This diff backports 7f0fb5e. Original commit message: - - - This is the miniooni related part of ooni/probe#1879. This diff will require backport to the release/3.11 branch. Conflicts: .github/workflows/miniooni.yml
3 tasks
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 23, 2021
This pull request changes `mk` and github workflows to build and publish binaries on tag. We also update the documentation to explain this new branching model. Basically, we have release branches where we produce binary packages and we add extra code, on tag, to publish such packages inside a release. We discussed removing most secrets from builds in this repository and having a different tool/repository that takes in input also secrets for doing follow-up actions after publishing. As a consequence, this pull request also removes all pieces of code that require secrets. The next step is to reinstate this code in this new repository/tool. The existing code in `mk` also implemented caching. This feature was useful when doing local builds because it reduced the time required to obtain binary releases. With builds running as part of GitHub actions, we don't need caching because we spawn parallel machines to build binaries. Therefore, let us also remove caching, which makes the code simpler. (Caching in itself is hard and in ooni/probe#1875 I noted that, for example, caching of the `ooni/go` repository was leading to some unwanted behaviour when changing the branch. Without caching, this behaviour is gone and we always generally use fresh information to produce builds.) Of course, this means that local builds are now slower, but I do not think this is a problem _because_ we want to use GitHub actions for building in the common case. Reference issues: ooni/probe#1879 and ooni/probe#1875. The final aspect to mention to conclude this description is an implementation one: ``` gh release create -p $tag --target $GITHUB_SHA || true ``` The code above uses `|| true` because there could already be a release. So, basically, it means that, if a release does not already exist, then we're going to create one. Otherwise, it does not matter because there's already a release.
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 23, 2021
… tag (#609) This diff forwardports 856e436 to the master branch Original commit message: - - - This pull request changes `mk` and github workflows to build and publish binaries on tag. We also update the documentation to explain this new branching model. Basically, we have release branches where we produce binary packages and we add extra code, on tag, to publish such packages inside a release. We discussed removing most secrets from builds in this repository and having a different tool/repository that takes in input also secrets for doing follow-up actions after publishing. As a consequence, this pull request also removes all pieces of code that require secrets. The next step is to reinstate this code in this new repository/tool. The existing code in `mk` also implemented caching. This feature was useful when doing local builds because it reduced the time required to obtain binary releases. With builds running as part of GitHub actions, we don't need caching because we spawn parallel machines to build binaries. Therefore, let us also remove caching, which makes the code simpler. (Caching in itself is hard and in ooni/probe#1875 I noted that, for example, caching of the `ooni/go` repository was leading to some unwanted behaviour when changing the branch. Without caching, this behaviour is gone and we always generally use fresh information to produce builds.) Of course, this means that local builds are now slower, but I do not think this is a problem _because_ we want to use GitHub actions for building in the common case. Reference issues: ooni/probe#1879 and ooni/probe#1875. The final aspect to mention to conclude this description is an implementation one: ``` gh release create -p $tag --target $GITHUB_SHA || true ``` The code above uses `|| true` because there could already be a release. So, basically, it means that, if a release does not already exist, then we're going to create one. Otherwise, it does not matter because there's already a release.
Merged
3 tasks
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 23, 2021
… tag (#609) (#611) This diff forwardports 856e436 to the master branch Original commit message: - - - This pull request changes `mk` and github workflows to build and publish binaries on tag. We also update the documentation to explain this new branching model. Basically, we have release branches where we produce binary packages and we add extra code, on tag, to publish such packages inside a release. We discussed removing most secrets from builds in this repository and having a different tool/repository that takes in input also secrets for doing follow-up actions after publishing. As a consequence, this pull request also removes all pieces of code that require secrets. The next step is to reinstate this code in this new repository/tool. The existing code in `mk` also implemented caching. This feature was useful when doing local builds because it reduced the time required to obtain binary releases. With builds running as part of GitHub actions, we don't need caching because we spawn parallel machines to build binaries. Therefore, let us also remove caching, which makes the code simpler. (Caching in itself is hard and in ooni/probe#1875 I noted that, for example, caching of the `ooni/go` repository was leading to some unwanted behaviour when changing the branch. Without caching, this behaviour is gone and we always generally use fresh information to produce builds.) Of course, this means that local builds are now slower, but I do not think this is a problem _because_ we want to use GitHub actions for building in the common case. Reference issues: ooni/probe#1879 and ooni/probe#1875. The final aspect to mention to conclude this description is an implementation one: ``` gh release create -p $tag --target $GITHUB_SHA || true ``` The code above uses `|| true` because there could already be a release. So, basically, it means that, if a release does not already exist, then we're going to create one. Otherwise, it does not matter because there's already a release.
|
done! |
bassosimone
added a commit
to ooni/probe-cli
that referenced
this issue
Nov 23, 2021
This fixes fetching an iOS release. Reference issue ooni/probe#1879. This diff will need to be forward ported.
bassosimone
added a commit
to ooni/probe-ios
that referenced
this issue
Nov 23, 2021
This (experimental?) diff points to the first version of oonimkall automatically built using the cloud. Unfortunately, my local system is quite in a bit of a broken state at the moment, after the macOS 12.0 system update. I'm going to use the CI to know whether the automatically built oonimkall works with the current probe-ios. Reference issue ooni/probe#1879.
bassosimone
added a commit
to ooni/probe-android
that referenced
this issue
Nov 24, 2021
bassosimone
added a commit
to ooni/probe-desktop
that referenced
this issue
Nov 24, 2021
This diff changes ooniprobe-desktop to use cli v3.11.0-beta.2. This cli release includes changes in the last (at this point six!) months to improve measurements quality. It is missing some extra fixes required to bless a stable release. Chiefly among them, the possiblity of running cleanly the DNSCheck experiment. I'm going to work on these issues as soon as possible. In the meanwhile, this release is a good testing base to check whether we have additional lingering issues. A few notes to explain this diff follows. First, I took the liberty of reducing as much as possible the amount of markdown linting warning I did see. Second, 3.11.0-beta.2 is the first release that is fully built using the cloud. I have not added any PGP key to the cloud as this seems a bit futile. Maybe it is not and maybe I'm not seeing the full picture, so we should discuss this topic. (I would not put my PGP key in there, and instead I'd put another key that has no password to sign releases; is this better than not using any key at all?) Third, cloud builds do not use tar.gz anymore. I did this to work around ooni/probe#1884 (in general, less pieces we use, less errors could occur.) As a result, the download script needed a bit of reworking. Fourth, while I reckon this is unlikely, I couldn't help noticing that the previous script did not download in case files were already on disk. To add a bit of robustness to this process, I am now prefixing the downloaded file with its version. This way, we'll re-download if there is a cli version change and there are already files on disk and, by some other mistake, the build rules are such that we don't clean existing files. The related issue is ooni/probe#1879
bassosimone
added a commit
to ooni/probe-android
that referenced
this issue
Dec 3, 2021
See ooni/probe#1879 Co-authored-by: Lorenzo Primiterra <[email protected]>
bassosimone
added a commit
to ooni/probe-ios
that referenced
this issue
Dec 3, 2021
This (experimental?) diff points to the first version of oonimkall automatically built using the cloud. Unfortunately, my local system is quite in a bit of a broken state at the moment, after the macOS 12.0 system update. I'm going to use the CI to know whether the automatically built oonimkall works with the current probe-ios. Reference issue ooni/probe#1879. Co-authored-by: Lorenzo Primiterra <[email protected]>
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this issue
Mar 8, 2022
This is the miniooni related part of ooni/probe#1879. This diff will require backport to the release/3.11 branch.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this issue
Mar 8, 2022
… tag (ooni#609) (ooni#611) This diff forwardports cc3a2f1862dfbff4846a536468cdfe37bca92534 to the master branch Original commit message: - - - This pull request changes `mk` and github workflows to build and publish binaries on tag. We also update the documentation to explain this new branching model. Basically, we have release branches where we produce binary packages and we add extra code, on tag, to publish such packages inside a release. We discussed removing most secrets from builds in this repository and having a different tool/repository that takes in input also secrets for doing follow-up actions after publishing. As a consequence, this pull request also removes all pieces of code that require secrets. The next step is to reinstate this code in this new repository/tool. The existing code in `mk` also implemented caching. This feature was useful when doing local builds because it reduced the time required to obtain binary releases. With builds running as part of GitHub actions, we don't need caching because we spawn parallel machines to build binaries. Therefore, let us also remove caching, which makes the code simpler. (Caching in itself is hard and in ooni/probe#1875 I noted that, for example, caching of the `ooni/go` repository was leading to some unwanted behaviour when changing the branch. Without caching, this behaviour is gone and we always generally use fresh information to produce builds.) Of course, this means that local builds are now slower, but I do not think this is a problem _because_ we want to use GitHub actions for building in the common case. Reference issues: ooni/probe#1879 and ooni/probe#1875. The final aspect to mention to conclude this description is an implementation one: ``` gh release create -p $tag --target $GITHUB_SHA || true ``` The code above uses `|| true` because there could already be a release. So, basically, it means that, if a release does not already exist, then we're going to create one. Otherwise, it does not matter because there's already a release.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See #1880 for rationale.
The text was updated successfully, but these errors were encountered: