Skip to content
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

Remove conda env #4

Closed
wants to merge 6 commits into from
Closed
Show file tree
Hide file tree
Changes from 2 commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
name: Python Package using Conda
name: Python Package build test
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

如果是展現用途的話,其實 python 本身不太重要,而是 backend,隨意想了一些候選的名稱

  • Backend CI
  • Backend Test


on:
push:
branches: ["backend"]
branches: ["backend*"]
pull_request:
branches: ["backend"]
branches: ["backend*"]
Copy link

@qrtt1 qrtt1 Jul 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

即使目前決定進 code 的部分,前端與後端看起來是以「平行時空」管理的,但最終大概會合併起來。

雖然還沒有用到,但事先提一下可以加 path filter 只關心特定的目錄。例如:

.
├── README.md
├── backend
│   └── foobar.py
└── frontend
    └── index.js
  • 後端的部分,可以只在 backend 有變化 (push event) 時跑簡單的 ci test。
  • 前端的部分,可以只在 frontend 有變化 (push event) 時跑簡單的 ci test。

當前端或後端發 PR 時,就任何一方有變化,就要跑 整合測試,因為 PR 的目標是為了「傳遞價值」。
白話地說

使用者拿在手上的東西,可以用以不能有明顯的壞掉。

在這個前提下,PR 真的要驗證的不是單方面的 前端後端,而是用 PR 狀態下的前後端一起 build 完,一起跑各種 test:

  • 重新打包並安裝前端
  • 重新打包並安裝後端
  • 測試後端的 e2e
  • 測試前端的 e2e
  • 啟動後端與前端,跑 integration test (比 e2e 更接近實際環境一些)

要做到上述的效果,那前後端在同一個「對得上版本的」single repo 就會是最容易的。

以目前分治的結構來看,分別去 clone 前端與後端最新的 code,其實都不是用一個「絕對的 revision (commit sha)」有一點刻舟求箭的感覺,最後 work-around 會變成:

  • 前端記錄一個後端的 revision,作為相容的版本
  • 後端記錄一個前端的 revision,作為相容的版本

這樣維護起來會更加疲勞。


jobs:
build-linux:
Expand All @@ -18,22 +18,15 @@ jobs:
uses: actions/setup-python@v3
with:
python-version: '3.10.11'
- name: Add conda to system path
run: |
# $CONDA is an environment variable pointing to the root of the miniconda directory
echo $CONDA/bin >> $GITHUB_PATH
- name: Install dependencies
run: |
# conda env update --file .yml --name base
pip install -r requirements.txt
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

習慣上會多一個 upgrade pip 本身的動作,因為 經歷了時空背景不同 之後有些套件因為更新後用舊的 pip 會安裝失敗。

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

目前requirements.txt內都是指定特定版本號碼去安裝,所以反而是比較擔心未來版本的pip 不支援所指定安裝版本套件

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

如果套件舊到新的 pip 裝不了,要考慮升級優先。不然,後續的開發團隊會很困擾。

- name: Lint with flake8
run: |
conda install flake8
# stop the build if there are Python syntax errors or undefined names
flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

設定要寫成 config file,這樣子 vscode 就可以一起使用了。在 CI 與開發時,用一樣的檢查規則,可以在開發期間提早知道要修改的東西。(另外,也有 flake8 的 github action 可以直接把 error 弄在 PR status line 上)

vscode 的設定可以參考 extension
https://github.com/microsoft/vscode-flake8

常見的還有 isort black 如果不會覺得 mypy 很煩,也可以考慮加一下。但它真的比較煩。

# exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics
- name: Test with pytest
run: |
conda install pytest
pytest
4 changes: 4 additions & 0 deletions requirements.txt
Original file line number Diff line number Diff line change
@@ -1,2 +1,6 @@
#app
flask == 2.3.2

#test
flake8 == 6.0.0
pytest == 7.3.1