c/ooni-probe-cli
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
92ebfd7986
ooni-probe-cli/mk

515 lines
22 KiB
Plaintext
Raw Normal View History

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
#!/usr/bin/make -f
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:
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: Usage: ./mk [VARIABLE=VALUE ...] TARGET ...
.PHONY: usage
usage:
@cat mk | grep '^#quickhelp:' | sed -e 's/^#quickhelp://' -e 's/^\ *//'
# Most targets are .PHONY because whether to rebuild is controlled
# by golang. We expose to the user all the .PHONY targets.
#quickhelp:
#quickhelp: The `./mk list-targets` command lists all available targets.
.PHONY: list-targets
list-targets:
@cat mk | grep '^\.PHONY:' | sed -e 's/^\.PHONY://'
#quickhelp:
#quickhelp: The `./mk help` command provides detailed usage instructions. We
#quickhelp: recommend running `./mk help|less` to page its output.
.PHONY: help
help:
@cat mk | grep -E '^#(quick)?help:' | sed -E -e 's/^#(quick)?help://' -e s'/^\ //'
#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: * ANDROID_CLI_SHA256 : the SHA256 of the Android CLI tools file. We always
#help: download the Linux version, which seems to work
#help: also on macOS (thank you, Java! :pray:).
chore(mk): update the version of the tools we use (#744) See https://github.com/ooni/probe/issues/2100
2022-05-19 22:09:54 +02:00
ANDROID_CLI_SHA256 = 5e7bf2dd563d34917d32f3c5920a85562a795c93
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: * ANDROID_CLI_VERSION : the version of the Android CLI tools.
chore(mk): update the version of the tools we use (#744) See https://github.com/ooni/probe/issues/2100
2022-05-19 22:09:54 +02:00
ANDROID_CLI_VERSION = 8512546
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: * ANDROID_INSTALL_EXTRA : contains the android tools we install in addition
#help: to the NDK in order to build oonimkall.aar.
feat: start preparing for a cli release (#672) This diff includes some final changes to be ready for blessing a cli release. These changes are: 1. run `go generate ./...` to update the bundled CA 2. update the header we use for measuring 3. ensure `mk` uses the latest version of several tools Reference issue: https://github.com/ooni/probe/issues/1845
2022-01-24 14:56:51 +01:00
ANDROID_INSTALL_EXTRA = 'build-tools;32.0.0' 'platforms;android-31'
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: * ANDROID_NDK_VERSION : Android NDK version.
fix(mk): use NDK version that works with gomobile (#748) The one we were using previously does not work, so use the LTS rather than using the latest non-LTS stable. Part of https://github.com/ooni/probe/issues/2100
2022-05-20 13:06:50 +02:00
ANDROID_NDK_VERSION = 23.1.7779620
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: * GIT_CLONE_DIR : directory where to clone repositories, by default
#help: set to `$HOME/.ooniprobe-build/src`.
GIT_CLONE_DIR = $(HOME)/.ooniprobe-build/src
# $(GIT_CLONE_DIR) is an internal target that creates $(GIT_CLONE_DIR).
$(GIT_CLONE_DIR):
mkdir -p $(GIT_CLONE_DIR)
#help:
#help: * GOLANG_EXTRA_FLAGS : extra flags passed to `go build ...`, empty by
#help: default. Useful to pass flags to `go`, e.g.:
#help:
#help: ./mk GOLANG_EXTRA_FLAGS="-x -v" ./CLI/miniooni
GOLANG_EXTRA_FLAGS =
#help:
#help: * GOLANG_VERSION_NUMBER : the expected version number for golang.
chore: upgrade to go1.18.2 (#750) I have not upgraded ooni/go yet because I am also checking whether it would be possible instead to use ooni/oocrypto as documented in the https://github.com/ooni/probe/issues/2106 issue. Closes https://github.com/ooni/probe/issues/2070 Closes https://github.com/ooni/probe/issues/2077
2022-05-22 18:11:37 +02:00
GOLANG_VERSION_NUMBER = 1.18.2
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: * MINGW_W64_VERSION : the expected mingw-w64 version.
MINGW_W64_VERSION = 10.3.1
#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:
#help: ./mk OONI_PSIPHON_TAGS="" ./CLI/miniooni
OONI_PSIPHON_TAGS = ooni_psiphon_config
#help:
#help: * OONI_ANDROID_HOME : directory where the Android SDK is downloaded
#help: and installed. You can point this to an existing
#help: copy of the SDK as long as (1) you have the
#help: right version of the command line tools, and
#help: (2) it's okay for us to install packages.
OONI_ANDROID_HOME = $(HOME)/.ooniprobe-build/sdk/android
#help:
#help: * XCODE_VERSION : the version of Xcode we expect.
chore(mk): update the version of the tools we use (#744) See https://github.com/ooni/probe/issues/2100
2022-05-19 22:09:54 +02:00
XCODE_VERSION = 13.3.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
#quickhelp:
#quickhelp: The `./mk show-config` command shows the current value of the
#quickhelp: variables controlling the build.
.PHONY: show-config
show-config:
@echo "ANDROID_CLI_VERSION=$(ANDROID_CLI_VERSION)"
@echo "ANDROID_CLI_SHA256=$(ANDROID_CLI_SHA256)"
@echo "ANDROID_INSTALL_EXTRA=$(ANDROID_INSTALL_EXTRA)"
@echo "ANDROID_NDK_VERSION=$(ANDROID_NDK_VERSION)"
@echo "GIT_CLONE_DIR=$(GIT_CLONE_DIR)"
@echo "GOLANG_EXTRA_FLAGS=$(GOLANG_EXTRA_FLAGS)"
@echo "GOLANG_VERSION_NUMBER=$(GOLANG_VERSION_NUMBER)"
@echo "MINGW_W64_VERSION=$(MINGW_W64_VERSION)"
@echo "OONI_PSIPHON_TAGS=$(OONI_PSIPHON_TAGS)"
@echo "OONI_ANDROID_HOME=$(OONI_ANDROID_HOME)"
@echo "XCODE_VERSION=$(XCODE_VERSION)"
# GOLANG_VERSION_STRING is the expected version string. If we
# run a golang binary that does not emit this version string
# when running `go version`, we stop the build.
GOLANG_VERSION_STRING = go$(GOLANG_VERSION_NUMBER)
# GOLANG_DOCKER_IMAGE is the golang docker image we use for
# building for Linux systems. It is an Alpine based container
# so that we can easily build static binaries.
GOLANG_DOCKER_IMAGE = golang:$(GOLANG_VERSION_NUMBER)-alpine
# Cross-compiling miniooni from any system with Go installed is
# very easy, because it does not use any C code.
#help:
#help: The `./mk ./CLI/miniooni` command builds the miniooni experimental
#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 \
./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
# All the miniooni targets build with CGO_ENABLED=0 such that the build
# succeeds when the GOOS/GOARCH is such that we aren't crosscompiling
# (e.g., targeting darwin/amd64 on darwin/amd64) _and_ there's no C compiler
# installed on the system. We can afford that since miniooni is pure Go.
#help:
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
#help: * `./mk ./CLI/miniooni-darwin-amd64`: darwin/amd64
.PHONY: ./CLI/miniooni-darwin-amd64
./CLI/miniooni-darwin-amd64: search/for/go maybe/copypsiphon
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
GOOS=darwin GOARCH=amd64 CGO_ENABLED=0 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
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
#help: * `./mk ./CLI/miniooni-darwin-arm64`: darwin/arm64
.PHONY: ./CLI/miniooni-darwin-arm64
./CLI/miniooni-darwin-arm64: search/for/go maybe/copypsiphon
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
GOOS=darwin GOARCH=arm64 CGO_ENABLED=0 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
# When building for Linux we use `-tags netgo` and `-extldflags -static` to produce
# a statically linked binary that completely bypasses libc.
#help:
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
#help: * `./mk ./CLI/miniooni-linux-386`: linux/386
.PHONY: ./CLI/miniooni-linux-386
./CLI/miniooni-linux-386: search/for/go maybe/copypsiphon
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
GOOS=linux GOARCH=386 CGO_ENABLED=0 go build -tags="netgo,$(OONI_PSIPHON_TAGS)" -ldflags="-s -w -extldflags -static" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
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
#help: * `./mk ./CLI/miniooni-linux-amd64`: linux/amd64
.PHONY: ./CLI/miniooni-linux-amd64
./CLI/miniooni-linux-amd64: search/for/go maybe/copypsiphon
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
GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go build -tags="netgo,$(OONI_PSIPHON_TAGS)" -ldflags="-s -w -extldflags -static" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
# When building for GOARCH=arm, we always force GOARM=7 (i.e., armhf/armv7).
#help:
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
#help: * `./mk ./CLI/miniooni-linux-armv7`: linux/armv7
.PHONY: ./CLI/miniooni-linux-armv7
./CLI/miniooni-linux-armv7: search/for/go maybe/copypsiphon
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
GOOS=linux GOARCH=arm CGO_ENABLED=0 GOARM=7 go build -tags="netgo,$(OONI_PSIPHON_TAGS)" -ldflags="-s -w -extldflags -static" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
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
#help: * `./mk ./CLI/miniooni-linux-arm64`: linux/arm64
.PHONY: ./CLI/miniooni-linux-arm64
./CLI/miniooni-linux-arm64: search/for/go maybe/copypsiphon
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
GOOS=linux GOARCH=arm64 CGO_ENABLED=0 go build -tags="netgo,$(OONI_PSIPHON_TAGS)" -ldflags="-s -w -extldflags -static" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
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
#help: * `./mk ./CLI/miniooni-windows-386.exe`: windows/386
.PHONY: ./CLI/miniooni-windows-386.exe
./CLI/miniooni-windows-386.exe: search/for/go maybe/copypsiphon
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
GOOS=windows GOARCH=386 CGO_ENABLED=0 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
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
#help: * `./mk ./CLI/miniooni-windows-amd64.exe`: windows/amd64
.PHONY: ./CLI/miniooni-windows-amd64.exe
./CLI/miniooni-windows-amd64.exe: search/for/go maybe/copypsiphon
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
GOOS=windows GOARCH=amd64 CGO_ENABLED=0 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./internal/cmd/miniooni
#help:
[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: The `./mk ./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
# We force CGO_ENABLED=1 because in principle we may be cross compiling. In
# reality it's hard to see a macOS/darwin build not made on macOS.
#help:
[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: * `./mk ./CLI/ooniprobe-darwin-amd64`: darwin/amd64
.PHONY: ./CLI/ooniprobe-darwin-amd64
./CLI/ooniprobe-darwin-amd64: search/for/go maybe/copypsiphon
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
GOOS=darwin GOARCH=amd64 CGO_ENABLED=1 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./cmd/ooniprobe
#help:
[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: * `./mk ./CLI/ooniprobe-darwin-arm64`: darwin/arm64
.PHONY: ./CLI/ooniprobe-darwin-arm64
./CLI/ooniprobe-darwin-arm64: search/for/go maybe/copypsiphon
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
GOOS=darwin GOARCH=arm64 CGO_ENABLED=1 go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./cmd/ooniprobe
#help:
[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: The `./mk ./CLI/ooniprobe-linux` command builds the ooniprobe official command
#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 \
./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
# Linux builds use Alpine and Docker so we are sure that we are statically
# linking to musl libc, thus making our binaries extremely portable.
#help:
[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: * `./mk ./CLI/ooniprobe-linux-386`: linux/386
.PHONY: ./CLI/ooniprobe-linux-386
./CLI/ooniprobe-linux-386: search/for/docker maybe/copypsiphon
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
docker pull --platform linux/386 $(GOLANG_DOCKER_IMAGE)
[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
docker run --platform linux/386 -e GOPATH=/gopath -e GOARCH=386 -v $(shell pwd):/ooni -w /ooni $(GOLANG_DOCKER_IMAGE) ./CLI/build-linux -tags=netgo,$(OONI_PSIPHON_TAGS) $(GOLANG_EXTRA_FLAGS)
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:
[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: * `./mk ./CLI/ooniprobe-linux-amd64`: linux/amd64
.PHONY: ./CLI/ooniprobe-linux-amd64
./CLI/ooniprobe-linux-amd64: search/for/docker maybe/copypsiphon
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
docker pull --platform linux/amd64 $(GOLANG_DOCKER_IMAGE)
[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
docker run --platform linux/amd64 -e GOPATH=/gopath -e GOARCH=amd64 -v $(shell pwd):/ooni -w /ooni $(GOLANG_DOCKER_IMAGE) ./CLI/build-linux -tags=netgo,$(OONI_PSIPHON_TAGS) $(GOLANG_EXTRA_FLAGS)
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:
[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: * `./mk ./CLI/ooniprobe-linux-armv7`: linux/arm
.PHONY: ./CLI/ooniprobe-linux-armv7
./CLI/ooniprobe-linux-armv7: search/for/docker maybe/copypsiphon
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
docker pull --platform linux/arm/v7 $(GOLANG_DOCKER_IMAGE)
[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
docker run --platform linux/arm/v7 -e GOPATH=/gopath -e GOARCH=arm -e GOARM=7 -v $(shell pwd):/ooni -w /ooni $(GOLANG_DOCKER_IMAGE) ./CLI/build-linux -tags=netgo,$(OONI_PSIPHON_TAGS) $(GOLANG_EXTRA_FLAGS)
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:
[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: * `./mk ./CLI/ooniprobe-linux-arm64`: linux/arm64
.PHONY: ./CLI/ooniprobe-linux-arm64
./CLI/ooniprobe-linux-arm64: search/for/docker maybe/copypsiphon
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
docker pull --platform linux/arm64 $(GOLANG_DOCKER_IMAGE)
[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
docker run --platform linux/arm64 -e GOPATH=/gopath -e GOARCH=arm64 -v $(shell pwd):/ooni -w /ooni $(GOLANG_DOCKER_IMAGE) ./CLI/build-linux -tags=netgo,$(OONI_PSIPHON_TAGS) $(GOLANG_EXTRA_FLAGS)
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:
[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: The `./mk ./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:
#help: * `./mk ./CLI/ooniprobe-windows-386.exe`: windows/386
.PHONY: ./CLI/ooniprobe-windows-386.exe
./CLI/ooniprobe-windows-386.exe: search/for/go search/for/mingw-w64 maybe/copypsiphon
GOOS=windows GOARCH=386 CGO_ENABLED=1 CC=i686-w64-mingw32-gcc go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./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:
[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: * `./mk ./CLI/ooniprobe-windows-amd64.exe`: windows/amd64
.PHONY: ./CLI/ooniprobe-windows-amd64.exe
./CLI/ooniprobe-windows-amd64.exe: search/for/go search/for/mingw-w64 maybe/copypsiphon
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
GOOS=windows GOARCH=amd64 CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc go build -tags="$(OONI_PSIPHON_TAGS)" -ldflags="-s -w" $(GOLANG_EXTRA_FLAGS) -o $@ ./cmd/ooniprobe
#help:
#help: The `./mk ./MOBILE/android` command builds the oonimkall library for Android.
#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:
#help: * `./mk ./MOBILE/android/oonimkall.pom`: the POM
.PHONY: ./MOBILE/android/oonimkall.pom
./MOBILE/android/oonimkall.pom:
cat ./MOBILE/android/template.pom | sed -e "s/@VERSION@/$(OONIMKALL_V)/g" > ./MOBILE/android/oonimkall.pom
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
# GOMOBILE is the full path location to the gomobile binary. We want to
# execute this command every time, because its output may depend on context,
# for this reason WE ARE NOT using `:=`.
GOMOBILE = $(shell go env GOPATH)/bin/gomobile
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:
#help: * `./mk ./MOBILE/android/oonimkall.aar`: the AAR
.PHONY: ./MOBILE/android/oonimkall.aar
./MOBILE/android/oonimkall.aar: android/sdk maybe/copypsiphon
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
go get -u golang.org/x/mobile/cmd/gomobile
$(GOMOBILE) init
[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
PATH=$(shell go env GOPATH)/bin:$$PATH ANDROID_HOME=$(OONI_ANDROID_HOME) ANDROID_NDK_HOME=$(OONI_ANDROID_HOME)/ndk/$(ANDROID_NDK_VERSION) $(GOMOBILE) bind -x -target android -o ./MOBILE/android/oonimkall.aar -tags="$(OONI_PSIPHON_TAGS)" -ldflags '-s -w' $(GOLANG_EXTRA_FLAGS) ./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:
#help: The `./mk ./MOBILE/ios` command builds the oonimkall library for iOS.
#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:
[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
#help: * `./mk ./MOBILE/ios/oonimkall.xcframework.zip`: zip the xcframework
.PHONY: ./MOBILE/ios/oonimkall.xcframework.zip
./MOBILE/ios/oonimkall.xcframework.zip: search/for/zip ./MOBILE/ios/oonimkall.xcframework
cd ./MOBILE/ios && rm -rf oonimkall.xcframework.zip
cd ./MOBILE/ios && zip -yr oonimkall.xcframework.zip oonimkall.xcframework
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:
[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
#help: * `./mk ./MOBILE/ios/xcframework`: the xcframework
.PHONY: ./MOBILE/ios/oonimkall.xcframework
./MOBILE/ios/oonimkall.xcframework: search/for/go search/for/xcode maybe/copypsiphon
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
go get -u golang.org/x/mobile/cmd/gomobile
$(GOMOBILE) init
PATH=$(shell go env GOPATH)/bin:$$PATH $(GOMOBILE) bind -target ios -o $@ -tags="$(OONI_PSIPHON_TAGS)" -ldflags '-s -w' $(GOLANG_EXTRA_FLAGS) ./pkg/oonimkall
#help:
#help: * `./mk ./MOBILE/ios/oonimkall.podspec`: the podspec
.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: 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
cat $< | sed -e "s/@VERSION@/$(OONIMKALL_V)/g" -e "s/@RELEASE@/$(OONIMKALL_R)/g" > $@
# important: OONIMKALL_V and OONIMKALL_R MUST be expanded just once so we use `:=`
OONIMKALL_V := $(shell date -u +%Y.%m.%d-%H%M%S)
OONIMKALL_R := $(shell git describe --tags || echo '0.0.0-dev')
#help:
#help: The following commands check for the availability of dependencies:
# TODO(bassosimone): make checks more robust?
#help:
#help: * `./mk search/for/bash`: checks for bash
.PHONY: search/for/bash
search/for/bash:
@printf "checking for bash... "
@command -v bash || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/curl`: checks for curl
.PHONY: search/for/curl
search/for/curl:
@printf "checking for curl... "
@command -v curl || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/docker`: checks for docker
.PHONY: search/for/docker
search/for/docker:
@printf "checking for docker... "
@command -v docker || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/git`: checks for git
.PHONY: search/for/git
search/for/git:
@printf "checking for git... "
@command -v git || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/go`: checks for go
.PHONY: search/for/go
search/for/go:
@printf "checking for go... "
@command -v go || { echo "not found"; exit 1; }
@printf "checking for go version... "
@echo $(__GOVERSION_REAL)
@[ "$(GOLANG_VERSION_STRING)" = "$(__GOVERSION_REAL)" ] || { echo "fatal: go version must be $(GOLANG_VERSION_STRING) instead of $(__GOVERSION_REAL)"; exit 1; }
# __GOVERSION_REAL is the go version reported by the go binary (we
# SHOULD NOT cache this value so we ARE NOT using `:=`)
__GOVERSION_REAL = $(shell go version | awk '{print $$3}')
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
#help:
#help: * `./mk search/for/java`: checks for java
.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
#help:
#help: * `./mk search/for/mingw-w64`: checks for mingw-w64
.PHONY: search/for/mingw-w64
search/for/mingw-w64:
@printf "checking for x86_64-w64-mingw32-gcc... "
@command -v x86_64-w64-mingw32-gcc || { echo "not found"; exit 1; }
@printf "checking for x86_64-w64-mingw32-gcc version... "
@echo $(__MINGW32_AMD64_VERSION)
@[ "$(MINGW_W64_VERSION)" = "$(__MINGW32_AMD64_VERSION)" ] || { echo "fatal: x86_64-w64-mingw32-gcc version must be $(MINGW_W64_VERSION) instead of $(__MINGW32_AMD64_VERSION)"; exit 1; }
@printf "checking for i686-w64-mingw32-gcc... "
@command -v i686-w64-mingw32-gcc || { echo "not found"; exit 1; }
@printf "checking for i686-w64-mingw32-gcc version... "
@echo $(__MINGW32_386_VERSION)
@[ "$(MINGW_W64_VERSION)" = "$(__MINGW32_386_VERSION)" ] || { echo "fatal: i686-w64-mingw32-gcc version must be $(MINGW_W64_VERSION) instead of $(__MINGW32_386_VERSION)"; exit 1; }
# __MINGW32_AMD64_VERSION and __MINGW32_386_VERSION are the versions
# reported by the amd64 and 386 mingw binaries.
__MINGW32_AMD64_VERSION = $(shell x86_64-w64-mingw32-gcc --version | sed -n 1p | awk '{print $$3}')
__MINGW32_386_VERSION = $(shell i686-w64-mingw32-gcc --version | sed -n 1p | awk '{print $$3}')
#help:
#help: * `./mk search/for/shasum`: checks for shasum
.PHONY: search/for/shasum
search/for/shasum:
@printf "checking for shasum... "
@command -v shasum || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/xcode`: checks for Xcode
.PHONY: search/for/xcode
search/for/xcode:
@printf "checking for xcodebuild... "
@command -v xcodebuild || { echo "not found"; exit 1; }
@printf "checking for Xcode version... "
@echo $(__XCODEVERSION_REAL)
@[ "$(XCODE_VERSION)" = "$(__XCODEVERSION_REAL)" ] || { echo "fatal: Xcode version must be $(XCODE_VERSION) instead of $(__XCODEVERSION_REAL)"; exit 1; }
# __XCODEVERSION_REAL is the version of Xcode obtained using xcodebuild
__XCODEVERSION_REAL = `xcodebuild -version | grep ^Xcode | awk '{print $$2}'`
#help:
#help: * `./mk search/for/unzip`: checks for unzip
.PHONY: search/for/unzip
search/for/unzip:
@printf "checking for unzip... "
@command -v unzip || { echo "not found"; exit 1; }
#help:
#help: * `./mk search/for/zip`: checks for zip
.PHONY: search/for/zip
search/for/zip:
@printf "checking for zip... "
@command -v zip || { echo "not found"; exit 1; }
#help:
[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: The `./mk maybe/copypsiphon` command checks whether we want
#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: 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 \
echo "copying psiphon configuration file into ./internal/engine"; \
$(MAKE) -f mk $(OONIPRIVATE) || exit 1; \
cp $(OONIPRIVATE)/psiphon-config.key ./internal/engine || exit 1; \
cp $(OONIPRIVATE)/psiphon-config.json.age ./internal/engine || exit 1; \
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
# OONIPRIVATE is the directory where we clone the private repository.
OONIPRIVATE = $(GIT_CLONE_DIR)/github.com/ooni/probe-private
# OONIPRIVATE_REPO is the private repository URL.
OONIPRIVATE_REPO = git@github.com:ooni/probe-private
# $(OONIPRIVATE) clones the private repository in $(GIT_CLONE_DIR)
$(OONIPRIVATE): search/for/git $(GIT_CLONE_DIR)
[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
rm -rf $(OONIPRIVATE)
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
git clone $(OONIPRIVATE_REPO) $(OONIPRIVATE)
#help:
#help: The `./mk android/sdk` command ensures we are using the
#help: correct version of the Android sdk.
.PHONY: android/sdk
android/sdk: search/for/java
[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
rm -rf $(OONI_ANDROID_HOME)
$(MAKE) -f mk android/sdk/download
[forwardport] mk: update ooni/go and Android build tools (#590) (#591) This diff forward ports abd212d014783cb96eaf821e9bb9a7b01039f837. Original commit message: - - - This diff upgrades `./mk` to use go1.17.3 rather than go1.16. While there, also update other Android build tools. This diff WILL need a forwardport to master. Closes https://github.com/ooni/probe/issues/1863.
2021-11-10 14:51:59 +01:00
test -f $(__ANDROID_SDKMANAGER) || { echo "please run './mk android/sdk/download'"; 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
echo "Yes" | $(__ANDROID_SDKMANAGER) --install $(ANDROID_INSTALL_EXTRA) 'ndk;$(ANDROID_NDK_VERSION)'
# __ANDROID_SKDMANAGER is the path to android's sdkmanager tool
__ANDROID_SDKMANAGER = $(OONI_ANDROID_HOME)/cmdline-tools/$(ANDROID_CLI_VERSION)/bin/sdkmanager
# See https://stackoverflow.com/a/61176718 to understand why
# we need to reorganize the directories like this:
#help:
#help: The `./mk android/sdk/download` unconditionally downloads the
#help: Android SDK at `$(OONI_ANDROID_HOME)`.
android/sdk/download: search/for/curl search/for/java search/for/shasum search/for/unzip
curl -fsSLO https://dl.google.com/android/repository/$(__ANDROID_CLITOOLS_FILE)
echo "$(ANDROID_CLI_SHA256) $(__ANDROID_CLITOOLS_FILE)" > __SHA256
shasum --check __SHA256
rm -f __SHA256
unzip $(__ANDROID_CLITOOLS_FILE)
rm $(__ANDROID_CLITOOLS_FILE)
mkdir -p $(OONI_ANDROID_HOME)/cmdline-tools
mv cmdline-tools $(OONI_ANDROID_HOME)/cmdline-tools/$(ANDROID_CLI_VERSION)
# __ANDROID_CLITOOLS_FILE is the file name of the android cli tools zip
__ANDROID_CLITOOLS_FILE = commandlinetools-linux-$(ANDROID_CLI_VERSION)_latest.zip
Reference in New Issue Copy Permalink