-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Airbyte-Ci: Add makefile for new tool installation #32484
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
62bdcb4
to
3da4c81
Compare
@@ -40,6 +40,7 @@ poethepoet = "^0.24.2" | |||
|
|||
[tool.poetry.scripts] | |||
airbyte-ci = "pipelines.cli.airbyte_ci:airbyte_ci" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left this in for now as I have a hope that the auto upgrade feature will install the binary automatically for people
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make tools.airbyte-ci.install
worked for me!
I made a couple of suggestions, let me know what you think.
My main one is:
- Now that we have a binary can we discard the use of
pipx
and encourageairbyte-ci
developers to iterate usingpoetry run airbyte-ci
?
Makefile
Outdated
|
||
tools.install: tools.airbyte-ci.install tools.check.airbyte-ci | ||
|
||
.PHONY: tools.install tools.airbyte-ci.install tools.airbyte-ci-dev.install |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of .PHONY
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makefile
Outdated
echo "airbyte-ci is either not on the PATH or not pointing to $$EXPECTED_PATH"; \ | ||
echo "Check that airbyte-ci exists at $$HOME/.local/bin and $$HOME/.local/bin is part the PATH"; \ | ||
echo "If it does try running removing all instances of airbyte-ci on your path, then run `make tools.install` again"; \ | ||
exit 1; \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we be more explicit by:
- explaining how to remove the pipx previous install from the path
- explaining how to add
$$HOME/.local/bin
to the path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can do "explaining how to remove the pipx previous install from the path" for sure by pointing to using a clean method. Explaining how to add to a path may be better left for the user to google
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default .local should be part of the path though. So hopefully we dont run into this
Makefile
Outdated
tools.airbyte-ci-dev.install: ## Install the development version of airbyte-ci | ||
##@ Install airbyte-ci development version | ||
pipx install --editable --force --python=python3.10 airbyte-ci/connectors/pipelines/; \ | ||
echo "Development version of airbyte-ci installed."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we discard the dev mode and encourage airbyte-ci developers to use poetry run airbyte-ci
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The thing is I think they both have their place?
poetry is useful for intense development where you are updating dependencys (particularly local ones)
pipx is useful if you want to install the dev version of the tool and use it in other areas of the code base (where you may need a different virtual env)
Im thinking in the makefile we use pipx for dev as its likely the entry point for "A non connector ops dev looking to test out a airbyte-ci change in their area of the code base"
Then in the setup readme for airbyte-ci push people to use poetry as thats the likely entry point for "A connector ops dev looking to make large updates to airbyte-ci"
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense, I have the impression that A non connector ops dev looking to test out a airbyte-ci change in their area of the code base is not common ATM, but let's not block this use case 👍
Makefile
Outdated
fi; \ | ||
echo "airbyte-ci is correctly installed at $$EXPECTED_PATH" | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we add a clean
/ uninstall
command called before install
that would:
- run
pipx uninstall pipelines
- delete any existing
airbyte-ci
in the path?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im team clean as a standalone step!
but we probably dont want it before install because
- It would be a time penalty
- In the binary future it would be unessesary as pipx should have gone away for all but c-ops devs
9a6dae7
to
d806391
Compare
d806391
to
9e4dcf6
Compare
@alafanechere This is back and ready for review
I also left 2 follow ups for you on
that I would love your thoughts on |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few comments but nothing major.
tools/bin/make/airbyte_ci_check.sh
Outdated
@@ -0,0 +1,30 @@ | |||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know why but I was told that #!/usr/bin/env bash
is preferable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tools/bin/make/airbyte_ci_check.sh
Outdated
@@ -0,0 +1,30 @@ | |||
#!/bin/bash | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
set -o errexit -o nounset -o pipefail
in all bash scripts.
Consider running these through the shellcheck linter.
# Check if pyenv is installed, and install it if not | ||
if ! which pyenv >/dev/null; then | ||
echo "pyenv not found, installing pyenv..." | ||
brew install pyenv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather you fail with an error message telling the user to brew install pyenv
. Perhaps that's just me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree
tools/bin/make/airbyte_ci_install.sh
Outdated
mkdir -p ~/.local/bin | ||
|
||
# Remove the old binary if it exists | ||
rm -f ~/.local/bin/airbyte-ci |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider curl
ing the new binary first, before removing the old one. The download may fail and then the user is up the proverbial creek.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah fair. I got lazy and ignored doing a tmp folder
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you create a temp folder then you also need to add an exit trap to clean it up and those are easy to not get right. Consider doing a curl -o
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did have -o set. but it was failing to overwrite and kept leaving the dev sym link.
Ill look into it a bit more
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did some research, the main pain is that curls download will follow the symbolic link.
To get it not to, or to delete the symbolic link with a fallback that recreates it is a bit of fiddly code
https://superuser.com/questions/303559/replace-symbolic-links-with-files
Given that once the binary is widely used we will be removing the airbyte-ci
python entry point in favour of airbyte-ci-dev
this symlink issue should go away.
so for not I opted to only delete the destination path when its a symlink.
Worst case scenario they run clean and install again
tools.install: tools.airbyte-ci.install tools.airbyte-ci.check | ||
|
||
.PHONY: tools.install tools.airbyte-ci.install tools.airbyte-ci-dev.install tools.airbyte-ci.check tools.airbyte-ci.clean | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want this makefile in the root? Seems like it should be in airbyte-ci
? Just a thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good callout. Im thinking that this makefile can become an entry point for setting up other tools. Like precommit hooks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice stuff here! I tried the flow of clean / dev install / normal install and it worked 👍
I added minor suggestions.
About the gradle
install I think we should do it (here or in a followup PR), because otherwise java developers will always use the "dev version" that we might don't want to release... It can make it harder to reproduce their problems. Feel free to do it in a separate PR.
# Check if pyenv is installed, and install it if not | ||
if ! which pyenv >/dev/null; then | ||
echo "pyenv not found, installing pyenv..." | ||
brew install pyenv |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree
# Check if pyenv is installed, and install it if not | ||
if ! which pyenv >/dev/null; then | ||
echo "pyenv not found, installing pyenv..." | ||
brew install pyenv | ||
echo "pyenv installed." | ||
else | ||
echo "pyenv is already installed." | ||
fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure pyenv is a requirement here... I think the requirement is that the current Python version is 3.10, and pyenv is a tool to switch Python version. pipx install --editable --force --python=python3.10 airbyte-ci/connectors/pipelines/
will fail if the user is not on python3.10
.
My suggestion is to make this script only check that the output of python --version
matches Python 3.10.*
. In case of error we can suggest users to:
brew install pyenv
pyenv install 3.10.12
pyenv shell 3.10.12
But we actually don't care if users use pyenv
or any other tool to install python 3.10.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moreover, if executed from the repo root, pyenv won't detect that the version we want to use is 3.10 as its defined in airbyte-ci/.python-version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call out, also worth specificying we do have a .python-version file in the root of the repo set to 3.10
https://github.com/airbytehq/airbyte/blob/89f6ecc0d0244cb24514f6011aa0d84a9b43f05b/.python-version#L0-L1
tools/bin/make/airbyte_ci_install.sh
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shall we keep these scripts under airbyte-ci/connectors/pipelines
? They're not coupled with make
anymore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good call, lets move them
…ci-binary-locally
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the auto_uppdate.py
.
I'm concerned by the fact that it strongly couples airbyte-ci
install/upgrade to our repo.
We can change this in follow up PRs when we'll try to make airbyte-ci
run outside of airbyte
repo, but I don't think it's not a heavy lift to take the less coupled approach I suggest.
BINARY_UPGRADE_COMMAND = "make tools.airbyte-ci.install" | ||
DEV_UPGRADE_COMMAND = "make tools.airbyte-ci-dev.install" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we make these upgrade command download and execute the shell scripts from https://raw.github.com
? The upgrade would otherwise be tied to the existence of the repo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You know what yes, me wanting to tie it to the makefile was wrong! Will change
Co-authored-by: Augustin <augustin@airbyte.io>
@alafanechere I took your usable outside the repo to heart and moved these install scripts from bash to python and exposed them with |
…ci-binary-locally
Makefile
Outdated
##@ Define the default version | ||
VERSION ?= latest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
##@ Define the default version | |
VERSION ?= latest | |
##@ Define the default airbyte-ci version | |
AIRBYTE_CI_VERSION ?= latest |
As this is the root Makefile I think its better to mention that the version is the airbyte-ci one.
""" | ||
OS = os.uname().sysname | ||
if OS == "Linux": | ||
print(f"Linux based system detected.") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest using rich
for nicer console output. https://github.com/Textualize/rich
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would love to! But thats the downside of this approach. We cannot add an thirdparty dependencies to these files.
If we do then we need the user to run a pip install
before they run the script.
This is why we have this disclaimer
airbyte/airbyte-ci/connectors/pipelines/pipelines/external_scripts/airbyte_ci_install.py
Line 4 in 4fca343
# Meaning, no external dependencies are allowed as we don't want users to have to run anything |
os.chmod(destination_path, 0o755) | ||
|
||
# ASCII Art and Completion Message | ||
install_complete_message = f""" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can go fancy here with rich-pixels
https://pypi.org/project/rich-pixels/
Super cool! Shall we expose a |
Current dependencies on/for this PR:
This stack of pull requests is managed by Graphite. |
Overview
closes #32562 #32561