Skip to content
Merged
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
9 changes: 9 additions & 0 deletions .github/workflows/test_conda-build.yml
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,8 @@ on:
paths:
- 'conda-environment.yml'
- '.github/workflows/test_conda-build.yml'
- 'pyproject.toml'
- 'setup.cfg'
schedule:
- cron: '17 22 * * 6' # Every Saturday at 22:17
workflow_dispatch:
Expand All @@ -31,6 +33,8 @@ jobs:
python-version: ['3.12', '3']
env:
ENV_FILE: conda-environment.yml
# prevent pip from meddling with the conda installed dependencies (during the conda build step)
PIP_NO_DEPS: True
steps:
- name: checkout cylc-flow
uses: actions/checkout@v5
Expand All @@ -52,8 +56,13 @@ jobs:
- name: check cylc installation
shell: bash -el {0}
run: |
# make sure Cylc is functioning
Copy link
Member

Choose a reason for hiding this comment

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

One thing I noticed when testing locally is that conda seems pretty keen on installing Python 3.12 even when the current is 3.14. Can we check that 3.14 is not being overridden?

Suggested change
# make sure Cylc is functioning
conda run -n test python --version
# make sure Cylc is functioning

Copy link
Member Author

Choose a reason for hiding this comment

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

That would just be testing the conda-incubator/setup-miniconda@v3 action?

Copy link
Member

@MetRonnie MetRonnie Oct 14, 2025

Choose a reason for hiding this comment

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

I'm concerned the python-version we specify is not working (e.g. for 3 it looks like we might be getting 3.12: https://github.com/cylc/cylc-flow/actions/runs/18500486273/job/52715670153?pr=7013#step:4:1438

Possibly this issue: conda-incubator/setup-miniconda#114

Copy link
Member Author

@oliver-sanders oliver-sanders Oct 14, 2025

Choose a reason for hiding this comment

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

Right.

We could hard pin the python version at the Conda level (i.e add python = <version> into the conda environment file) which should be as safe as the Conda environment itself (if that dependency brokering is broken, all bets are off).

Copy link
Member Author

@oliver-sanders oliver-sanders Oct 15, 2025

Choose a reason for hiding this comment

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

Implemented the above suggestion in c91c402

Unfold the last section in the "build Conda env" step to reveal the version installed.

Copy link
Member Author

@oliver-sanders oliver-sanders Oct 15, 2025

Choose a reason for hiding this comment

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

I we want to force our actions (including this one) to run with the latest Python, we'll have to explicitly state it.

But that's a right maintenance pain as we'll have to keep updating it :(

  • Using an action to extract the version is possible, but ugly, but at least automated.
  • Configuring it in a file is still a maintenance pain, but at least a centralised one.
  • Setting it as a repository secret/variable is a maintenance pain and non-obvious, but at least centralised.

Orthogonal to this new check either way, but probs something we should look into soon to help spot leading edge issues sooner as current tests ain't gonna do that.

Copy link
Member

Choose a reason for hiding this comment

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

Ah right, I was thinking of actions/setup-python which does this effortlessly. I guess updating the latest one once a year isn't too bad... But at present there is no point having a separate 3.12 and 3 in the matrix

Copy link
Member Author

@oliver-sanders oliver-sanders Oct 15, 2025

Choose a reason for hiding this comment

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

With setup-python, 3.x always picks the latest Python version for the operating system, not necessarily the latest Python.

With Conda, 3 always picks the latest Python compatible with the preferable solve of the environment, not necessarily the latest Python.

Neither is perfect, but setup-python is more likely to give the preferred answer more of the time.

Specifying 3 isn't "pointless", once the dependency issue that this PR is identifying has been resolved, it will pick up 3.14 as intended.

Copy link
Member

@MetRonnie MetRonnie Oct 16, 2025

Choose a reason for hiding this comment

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

Ohhh it was choosing 3.12 because of the old protobuf pin, got it.

Still, it is useful to have a conda run -n test python --version or better yet conda list -n test step for debugging purposes

Copy link
Member Author

Choose a reason for hiding this comment

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

Yep. It isn't ideal that this can happen, am mulling possible workarounds for future...

conda run -n test cylc version --long

# make sure pip is happy with the packages installed
# (checks pip deps are compatible with conda deps)
conda run -n test pip check

- name: check for activate scripts
shell : bash -el {0}
run: |
Expand Down
Loading