c/ooni-probe-cli
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
d48d44b880
ooni-probe-cli/Makefile

326 lines
12 KiB
Makefile
Raw Normal View History

feat: build and publish debian/{armhf,i386} (#344) * feat: build and publish debian/{armhf,i386} Part of https://github.com/ooni/probe/issues/807 * zap temporary build
2021-05-11 20:16:27 +02:00
# Many rules in here break if run in parallel.
.NOTPARALLEL:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#quickhelp: Usage: make [VARIABLE=VALUE ...] TARGET ...
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: usage
usage:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
@cat Makefile | grep '^#quickhelp:' | sed -e 's/^#quickhelp://' -e 's/^\ *//'
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
# Most targets are .PHONY because whether to rebuild is controlled
# by golang. We expose to the user all the .PHONY targets.
#quickhelp:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#quickhelp: The `make list-targets` command lists all available targets.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: list-targets
list-targets:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
@cat Makefile | grep '^\.PHONY:' | sed -e 's/^\.PHONY://' | grep -v '^ search' | grep -v '^ maybe'
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#quickhelp:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#quickhelp: The `make help` command provides detailed usage instructions. We
#quickhelp: recommend running `make help|less` to page its output.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: help
help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
@cat Makefile | grep -E '^#(quick)?help:' | sed -E -e 's/^#(quick)?help://' -e s'/^\ //'
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: The following variables control the build. You can specify them
#help: on the command line as a key-value pairs (see usage above).
#help:
#help: * GIT_CLONE_DIR : directory where to clone repositories, by default
#help: set to `$HOME/.ooniprobe-build/src`.
GIT_CLONE_DIR = $(HOME)/.ooniprobe-build/src
#help:
#help: * OONI_PSIPHON_TAGS : build tags for `go build -tags ...` that cause
#help: the build to embed a psiphon configuration file
#help: into the generated binaries. This build tag
#help: implies cloning the git@github.com:ooni/probe-private
#help: repository. If you do not have the permission to
#help: clone it, just clear this variable, e.g.:
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: make OONI_PSIPHON_TAGS="" ./CLI/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
OONI_PSIPHON_TAGS = ooni_psiphon_config
#quickhelp:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#quickhelp: The `make show-config` command shows the current value of the
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#quickhelp: variables controlling the build.
.PHONY: show-config
show-config:
@echo "GIT_CLONE_DIR=$(GIT_CLONE_DIR)"
@echo "OONI_PSIPHON_TAGS=$(OONI_PSIPHON_TAGS)"
feat: build miniooni and ooniprobe for android (#907) This diff introduces a build script, makefile rules, and github actions rules to build and public android CLI releases. See https://github.com/ooni/probe/issues/1723
2022-08-30 09:37:15 +02:00
#help:
#help: The `make ./CLI/android` command builds miniooni and ooniprobe for
#help: all the supported Android architectures.
.PHONY: ./CLI/android
./CLI/android: search/for/go search/for/android/sdk maybe/copypsiphon
./CLI/go-build-android 386 ./internal/cmd/miniooni
./CLI/go-build-android 386 ./cmd/ooniprobe
./CLI/go-build-android amd64 ./internal/cmd/miniooni
./CLI/go-build-android amd64 ./cmd/ooniprobe
./CLI/go-build-android arm ./internal/cmd/miniooni
./CLI/go-build-android arm ./cmd/ooniprobe
./CLI/go-build-android arm64 ./internal/cmd/miniooni
./CLI/go-build-android arm64 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./CLI/miniooni` command builds the miniooni experimental
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help: command line client for all the supported GOOS/GOARCH.
#help:
#help: You can also build the following subtargets:
.PHONY: ./CLI/miniooni
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
./CLI/miniooni: \
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
./CLI/miniooni-darwin-amd64 \
./CLI/miniooni-darwin-arm64 \
./CLI/miniooni-linux-386 \
./CLI/miniooni-linux-amd64 \
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/miniooni-linux-armv6 \
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
./CLI/miniooni-linux-armv7 \
./CLI/miniooni-linux-arm64 \
./CLI/miniooni-windows-386.exe \
./CLI/miniooni-windows-amd64.exe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-darwin-amd64`: darwin/amd64
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-darwin-amd64
./CLI/miniooni-darwin-amd64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross darwin amd64 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-darwin-arm64`: darwin/arm64
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-darwin-arm64
./CLI/miniooni-darwin-arm64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross darwin arm64 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-linux-386`: linux/386
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-linux-386
./CLI/miniooni-linux-386: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross linux 386 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-linux-amd64`: linux/amd64
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-linux-amd64
./CLI/miniooni-linux-amd64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross linux amd64 ./internal/cmd/miniooni
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-linux-armv6`: linux/armv6
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
.PHONY: ./CLI/miniooni-linux-armv6
./CLI/miniooni-linux-armv6: search/for/go maybe/copypsiphon
./CLI/go-build-cross linux armv6 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-linux-armv7`: linux/armv7
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-linux-armv7
./CLI/miniooni-linux-armv7: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross linux armv7 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-linux-arm64`: linux/arm64
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-linux-arm64
./CLI/miniooni-linux-arm64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross linux arm64 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-windows-386.exe`: windows/386
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-windows-386.exe
./CLI/miniooni-windows-386.exe: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross windows 386 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/miniooni-windows-amd64.exe`: windows/amd64
feat: publish miniooni binaries into releases (#607) This is the miniooni related part of https://github.com/ooni/probe/issues/1879. This diff will require backport to the release/3.11 branch.
2021-11-22 13:40:36 +01:00
.PHONY: ./CLI/miniooni-windows-amd64.exe
./CLI/miniooni-windows-amd64.exe: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-cross windows amd64 ./internal/cmd/miniooni
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./CLI/ooniprobe-darwin` command builds the ooniprobe official
refactor: use ooni/oocrypto instead of ooni/go (#751) Rather than building for Android using ooni/go, we're now using ooni/oocryto as the TLS dependency. Such a repository only forks crypto/tls and some minor crypto packages and includes the same set of patches that we have been using in ooni/go. This new strategy should be better than the previous one in terms of building for Android, because we can use the vanilla go1.18.2 build. It also seems that it is easier to track and merge from upstream with ooni/oocrypto than it is with ooni/go. Should this assessment be wrong, we can revert back to the previous scenario where we used ooni/go. See https://github.com/ooni/probe/issues/2106 for extra context.
2022-05-22 19:53:37 +02:00
#help: command line client for darwin/amd64 and darwin/arm64.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: You can also build the following subtargets:
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-darwin
./CLI/ooniprobe-darwin: ./CLI/ooniprobe-darwin-amd64 ./CLI/ooniprobe-darwin-arm64
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-darwin-amd64`: darwin/amd64
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-darwin-amd64
./CLI/ooniprobe-darwin-amd64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-darwin amd64 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-darwin-arm64`: darwin/arm64
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-darwin-arm64
./CLI/ooniprobe-darwin-arm64: search/for/go maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-darwin arm64 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./CLI/ooniprobe-linux` command builds the ooniprobe official command
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
#help: line client for amd64, arm64, etc.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: You can also build the following subtargets:
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-linux
./CLI/ooniprobe-linux: \
./CLI/ooniprobe-linux-386 \
./CLI/ooniprobe-linux-amd64 \
feat: build ooniprobe for armv6 (#904) Part of https://github.com/ooni/probe/issues/1753. While there, introduce a rule by which, if the branch is named `fullbuild` we run all possible builds. It helps to test all the builds without creating a release branch. Because release branches are protected, they cannot be deleted easily. On the contrary, the `fullbuild` branch can easily be disposed of.
2022-08-29 17:33:42 +02:00
./CLI/ooniprobe-linux-armv6 \
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
./CLI/ooniprobe-linux-armv7 \
./CLI/ooniprobe-linux-arm64
feat: build and publish debian/{armhf,i386} (#344) * feat: build and publish debian/{armhf,i386} Part of https://github.com/ooni/probe/issues/807 * zap temporary build
2021-05-11 20:16:27 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-linux-386`: linux/386
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-linux-386
./CLI/ooniprobe-linux-386: search/for/docker maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-linux-static 386 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-linux-amd64`: linux/amd64
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-linux-amd64
./CLI/ooniprobe-linux-amd64: search/for/docker maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-linux-static amd64 ./cmd/ooniprobe
feat: build and publish debian/{armhf,i386} (#344) * feat: build and publish debian/{armhf,i386} Part of https://github.com/ooni/probe/issues/807 * zap temporary build
2021-05-11 20:16:27 +02:00
feat: build ooniprobe for armv6 (#904) Part of https://github.com/ooni/probe/issues/1753. While there, introduce a rule by which, if the branch is named `fullbuild` we run all possible builds. It helps to test all the builds without creating a release branch. Because release branches are protected, they cannot be deleted easily. On the contrary, the `fullbuild` branch can easily be disposed of.
2022-08-29 17:33:42 +02:00
#help:
#help: * `make ./CLI/ooniprobe-linux-armv6`: linux/arm
.PHONY: ./CLI/ooniprobe-linux-armv6
./CLI/ooniprobe-linux-armv6: search/for/docker maybe/copypsiphon
./CLI/go-build-linux-static armv6 ./cmd/ooniprobe
feat: build and publish debian/{armhf,i386} (#344) * feat: build and publish debian/{armhf,i386} Part of https://github.com/ooni/probe/issues/807 * zap temporary build
2021-05-11 20:16:27 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-linux-armv7`: linux/arm
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-linux-armv7
./CLI/ooniprobe-linux-armv7: search/for/docker maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-linux-static armv7 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-linux-arm64`: linux/arm64
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-linux-arm64
./CLI/ooniprobe-linux-arm64: search/for/docker maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-linux-static arm64 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./CLI/ooniprobe-windows` command builds the ooniprobe official
refactor: use ooni/oocrypto instead of ooni/go (#751) Rather than building for Android using ooni/go, we're now using ooni/oocryto as the TLS dependency. Such a repository only forks crypto/tls and some minor crypto packages and includes the same set of patches that we have been using in ooni/go. This new strategy should be better than the previous one in terms of building for Android, because we can use the vanilla go1.18.2 build. It also seems that it is easier to track and merge from upstream with ooni/oocrypto than it is with ooni/go. Should this assessment be wrong, we can revert back to the previous scenario where we used ooni/go. See https://github.com/ooni/probe/issues/2106 for extra context.
2022-05-22 19:53:37 +02:00
#help: command line client for windows/386 and windows/amd64.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: You can also build the following subtargets:
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-windows
./CLI/ooniprobe-windows: \
./CLI/ooniprobe-windows-386.exe \
./CLI/ooniprobe-windows-amd64.exe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-windows-386.exe`: windows/386
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-windows-386.exe
./CLI/ooniprobe-windows-386.exe: search/for/go search/for/mingw-w64 maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-windows 386 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./CLI/ooniprobe-windows-amd64.exe`: windows/amd64
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./CLI/ooniprobe-windows-amd64.exe
./CLI/ooniprobe-windows-amd64.exe: search/for/go search/for/mingw-w64 maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/go-build-windows amd64 ./cmd/ooniprobe
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./MOBILE/android` command builds the oonimkall library for Android.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: You can also build the following subtargets:
.PHONY: ./MOBILE/android
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
./MOBILE/android: ./MOBILE/android/oonimkall.aar ./MOBILE/android/oonimkall.pom
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./MOBILE/android/oonimkall.pom`: the POM
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
.PHONY: ./MOBILE/android/oonimkall.pom
./MOBILE/android/oonimkall.pom:
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/android/createpom
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
refactor: use ooni/oocrypto instead of ooni/go (#751) Rather than building for Android using ooni/go, we're now using ooni/oocryto as the TLS dependency. Such a repository only forks crypto/tls and some minor crypto packages and includes the same set of patches that we have been using in ooni/go. This new strategy should be better than the previous one in terms of building for Android, because we can use the vanilla go1.18.2 build. It also seems that it is easier to track and merge from upstream with ooni/oocrypto than it is with ooni/go. Should this assessment be wrong, we can revert back to the previous scenario where we used ooni/go. See https://github.com/ooni/probe/issues/2106 for extra context.
2022-05-22 19:53:37 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./MOBILE/android/oonimkall.aar`: the AAR
refactor: use ooni/oocrypto instead of ooni/go (#751) Rather than building for Android using ooni/go, we're now using ooni/oocryto as the TLS dependency. Such a repository only forks crypto/tls and some minor crypto packages and includes the same set of patches that we have been using in ooni/go. This new strategy should be better than the previous one in terms of building for Android, because we can use the vanilla go1.18.2 build. It also seems that it is easier to track and merge from upstream with ooni/oocrypto than it is with ooni/go. Should this assessment be wrong, we can revert back to the previous scenario where we used ooni/go. See https://github.com/ooni/probe/issues/2106 for extra context.
2022-05-22 19:53:37 +02:00
.PHONY: ./MOBILE/android/oonimkall.aar
fix(MOBILE/android): make scripts monorepo compatible (#866) This diff contains minor changes to make the build scripts in here compatible with https://github.com/bassosimone/monorepo. See https://github.com/bassosimone/monorepo/commit/5e4c7973801dbd1a582cd21d5000e09a2ee630a7
2022-08-17 18:47:09 +02:00
./MOBILE/android/oonimkall.aar: search/for/go search/for/android/sdk maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/gomobile android ./pkg/oonimkall
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make ./MOBILE/ios` command builds the oonimkall library for iOS.
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
#help: You can also build the following subtargets:
.PHONY: ./MOBILE/ios
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
./MOBILE/ios: ./MOBILE/ios/oonimkall.xcframework.zip ./MOBILE/ios/oonimkall.podspec
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./MOBILE/ios/oonimkall.xcframework.zip`: zip the xcframework
[forwardport] fix(ios): make sure we can build an iOS release (#598) (#599) This diff forward ports f47b0c6c16e0cd417e3591358eb85b45962f307d to master. Original commit message: - - - 1. we now need to name the framework `.xcframework` otherwise gomobile refuses to build a new framework for us ¯\_(ツ)_/¯ 2. remove duplicate errno definition for iOS (iOS and darwin are considered the same, therefore we don't need iOS defs) Reference issue for this PR: https://github.com/ooni/probe/issues/1876 This diff WILL need to be forwardported to master.
2021-11-15 14:24:20 +01:00
.PHONY: ./MOBILE/ios/oonimkall.xcframework.zip
./MOBILE/ios/oonimkall.xcframework.zip: search/for/zip ./MOBILE/ios/oonimkall.xcframework
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/ios/zipframework
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./MOBILE/ios/xcframework`: the xcframework
[forwardport] fix(ios): make sure we can build an iOS release (#598) (#599) This diff forward ports f47b0c6c16e0cd417e3591358eb85b45962f307d to master. Original commit message: - - - 1. we now need to name the framework `.xcframework` otherwise gomobile refuses to build a new framework for us ¯\_(ツ)_/¯ 2. remove duplicate errno definition for iOS (iOS and darwin are considered the same, therefore we don't need iOS defs) Reference issue for this PR: https://github.com/ooni/probe/issues/1876 This diff WILL need to be forwardported to master.
2021-11-15 14:24:20 +01:00
.PHONY: ./MOBILE/ios/oonimkall.xcframework
./MOBILE/ios/oonimkall.xcframework: search/for/go search/for/xcode maybe/copypsiphon
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/gomobile ios ./pkg/oonimkall
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: * `make ./MOBILE/ios/oonimkall.podspec`: the podspec
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: ./MOBILE/ios/oonimkall.podspec
[forwardport] ci/cd: publish binaries onto a release when we create a tag (#609) (#611) This diff forwardports 856e436e20d511a4f0d618546da7921fa9f8c5f6 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 https://github.com/ooni/probe/issues/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: https://github.com/ooni/probe/issues/1879 and https://github.com/ooni/probe/issues/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.
2021-11-23 15:56:25 +01:00
./MOBILE/ios/oonimkall.podspec: ./MOBILE/ios/template.podspec
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/ios/createpodspec
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: search/for/docker
search/for/docker:
@printf "checking for docker... "
@command -v docker || { echo "not found"; exit 1; }
.PHONY: search/for/git
search/for/git:
@printf "checking for git... "
@command -v git || { echo "not found"; exit 1; }
.PHONY: search/for/go
search/for/go:
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/check-go-version
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
fix(debian): make sure we can publish all archs (#350) We are mostly good to declare a stable release. We still need to deal with https://github.com/ooni/probe/issues/1484. In this PR, we fix the aforementioned issue. These are the changes: 1. we remove the vendored `debops-ci`, and we pull it directly from `ooni/sysadmin` 2. we introduce a new script, `./CLI/linux/pubdebian`, to publish packages 3. we modify `./mk` to allow for publishing debian packages built outside of CI The latter point has been quite useful in debugging what was wrong.
2021-05-19 13:54:19 +02:00
.PHONY: search/for/java
search/for/java:
@printf "checking for java... "
@command -v java || { echo "not found"; exit 1; }
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: search/for/mingw-w64
search/for/mingw-w64:
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./CLI/check-mingw-w64-version
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: search/for/xcode
search/for/xcode:
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./MOBILE/ios/check-xcode-version
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: search/for/zip
search/for/zip:
@printf "checking for zip... "
@command -v zip || { echo "not found"; exit 1; }
#help:
cleanup: chmod -x mk && mv mk Makefile (#863) While there, document what we need to document without mentioning too many details about release builds, for which we have the Makefile. See https://github.com/ooni/probe/issues/2218.
2022-08-17 13:46:41 +02:00
#help: The `make maybe/copypsiphon` command checks whether we want
[forwardport] fix(mk): do nothing if we already have psiphon config (#605) (#606) This diff forward ports ea44e99451f345474738b9010ff791759a1f1367. Original commit message: - - - This change allows for producing cloud builds using the psiphon config files. We will add those files as build secrets. Only people in the organization and collaborators with at least "write" access could trigger builds containing such secrets. Before this change, `./mk` unconditionally attempted to clone github.com/ooni/probe-private. Now, it only checks whether we need to clone _if_ files are not already there. This allows us to use GitHub actions and secrets to copy the files in there _without_ needing to clone a private repo. Cloning a private repo would require us to include as repository secret an access token with full `repo` scope, which is a very broad scope. Instead, by using secrets to include psiphon config, we are narrowing down the secrets required to make a release build. See https://github.com/ooni/probe/issues/1878 This diff WILL require forward porting to the master branch.
2021-11-19 12:40:10 +01:00
#help: to embed the Psiphon config file into the build. To this end,
#help: this command checks whether OONI_PSIPHON_TAGS is set. In
#help: such a case, this command checks whether the required files
#help: are already in place. If not, this command fetches them
#help: by cloning the github.com/ooni/probe-private repo.
#
# Note: we check for files being already there before attempting
# to clone _because_ we put files in there using secrets when
# running cloud builds. This saves us from including a token with
# `repo` scope as a build secret, which is a very broad scope.
#
# Cloning the private repository, instead, is the way in which
# local builds get access to the psiphon config files.
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
#
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
.PHONY: maybe/copypsiphon
maybe/copypsiphon: search/for/git
[forwardport] fix(mk): do nothing if we already have psiphon config (#605) (#606) This diff forward ports ea44e99451f345474738b9010ff791759a1f1367. Original commit message: - - - This change allows for producing cloud builds using the psiphon config files. We will add those files as build secrets. Only people in the organization and collaborators with at least "write" access could trigger builds containing such secrets. Before this change, `./mk` unconditionally attempted to clone github.com/ooni/probe-private. Now, it only checks whether we need to clone _if_ files are not already there. This allows us to use GitHub actions and secrets to copy the files in there _without_ needing to clone a private repo. Cloning a private repo would require us to include as repository secret an access token with full `repo` scope, which is a very broad scope. Instead, by using secrets to include psiphon config, we are narrowing down the secrets required to make a release build. See https://github.com/ooni/probe/issues/1878 This diff WILL require forward porting to the master branch.
2021-11-19 12:40:10 +01:00
@if test "$(OONI_PSIPHON_TAGS)" = "ooni_psiphon_config"; then \
if test ! -f ./internal/engine/psiphon-config.json.age -a \
! -f ./internal/engine/psiphon-config.key; then \
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
./script/copy-psiphon-files.bash $(GIT_CLONE_DIR) || exit 1; \
[forwardport] fix(mk): do nothing if we already have psiphon config (#605) (#606) This diff forward ports ea44e99451f345474738b9010ff791759a1f1367. Original commit message: - - - This change allows for producing cloud builds using the psiphon config files. We will add those files as build secrets. Only people in the organization and collaborators with at least "write" access could trigger builds containing such secrets. Before this change, `./mk` unconditionally attempted to clone github.com/ooni/probe-private. Now, it only checks whether we need to clone _if_ files are not already there. This allows us to use GitHub actions and secrets to copy the files in there _without_ needing to clone a private repo. Cloning a private repo would require us to include as repository secret an access token with full `repo` scope, which is a very broad scope. Instead, by using secrets to include psiphon config, we are narrowing down the secrets required to make a release build. See https://github.com/ooni/probe/issues/1878 This diff WILL require forward porting to the master branch.
2021-11-19 12:40:10 +01:00
fi; \
fi
refactor: replace ./make (python3) with ./mk (makefile) (#343) This pull request fixes https://github.com/ooni/probe/issues/1471. We have replaced the original build script (`./make`) with the `./mk` makefile (executable using `#!/usr/bin/make -f`). We concluded supporting direct builds from Windows is not worth the effort and halving the code we need to maintain is probably a good plus. Both macOS and Linux install GNU make at `/usr/bin/make`, so we should be okay in the common use cases. I significantly simplified the management of Go versioning by requiring the user to manage it and by enforcing that we are using the desired Go version. This speeds up builds and works in sane operating systems that use the last version of a specific package. Otherwise, it's possible to use the `go get golang.org/dl/go${version}` feature. The remaining question mark was related to updating the Android SDK. I have determined that a good course of action is pinning to the latest CLI tools and always forcing the CLI tools to install the latest required packages (e.g., the NDK).
2021-05-11 16:15:13 +02:00
refactor(mk): move build rules into separate scripts (#855) See https://github.com/ooni/probe/issues/2218
2022-08-17 13:16:53 +02:00
.PHONY: search/for/android/sdk
search/for/android/sdk: search/for/java
./MOBILE/android/ensure
Reference in New Issue Copy Permalink