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

Move CI to macos-14 #388

Draft
wants to merge 6 commits into
base: main
Choose a base branch
from
Draft

Move CI to macos-14 #388

wants to merge 6 commits into from

Conversation

xhochy
Copy link
Collaborator

@xhochy xhochy commented Jan 13, 2025

Description

@conda-bot conda-bot added the cla-signed [bot] added once the contributor has signed the CLA label Jan 13, 2025
@xhochy xhochy force-pushed the move-to-macos14 branch 2 times, most recently from dc22344 to e7862b6 Compare January 13, 2025 13:37
@xhochy
Copy link
Collaborator Author

xhochy commented Jan 13, 2025

@conda/constructor Does anyone know who can upload packages to the ctools channel? We would need an upload of the conda_pack_test_lib* packages for osx-arm64.

@jezdez
Copy link
Member

jezdez commented Jan 14, 2025

Hey @xhochy, I wonder, would it be a bad time to standardize on the conda-canary channel we've used for a number of OSS projects in the conda org for a while now? I think ctools may not be the right long-term channel to host these packages given the overlap with Anaconda-specific packages there.

@dbast
Copy link
Member

dbast commented Jan 14, 2025

@jezdez Not sure if that improves the situation ... those are not really canary packages and it would still require a specific person (non-transparent to others who that is) to build and upload those... until somebody writes a workflow to build + upload the package via gh secrets, but this workflow works then once and then rots as there is an upload every 10 years ;)

@dbast
Copy link
Member

dbast commented Jan 14, 2025

Looks like this is a single upload of conda_pack_test_lib2 for osx-arm64 ... conda_pack_test_lib1 is noarch anyways.

@jezdez
Copy link
Member

jezdez commented Jan 14, 2025

@jezdez Not sure if that improves the situation ... those are not really canary packages and it would still require a specific person (non-transparent to others who that is) to build and upload those... until somebody writes a workflow to build + upload the package via gh secrets, but this workflow works then once and then rots as there is an upload every 10 years ;)

That's what we did, https://github.com/conda/actions/tree/main/canary-release exists, and we're uploading several packages as canaries, conda and conda-build etc. How is ctools used at the moment?

@dbast
Copy link
Member

dbast commented Jan 14, 2025

I know the canary upload workflow... is it feasible to also use it for test packages uploads (not conda-pack itself)?

@dbast
Copy link
Member

dbast commented Jan 14, 2025

@xhochy the osx-arm64 uploads are done, see https://anaconda.org/ctools/conda_pack_test_lib2/files (note: there is no Python 3.7 upload as there is no Python 3.7 for osx-arm64 ... so the tests need some adjustments) ... ping me if we need more uploads ... or somebody writes a flow based on https://github.com/conda/actions/tree/main/canary-release for uploads in the future.

@dbast
Copy link
Member

dbast commented Jan 14, 2025

hah. its technically green now

though lots of variable and file names contain "py37" (even though we technically install python 3.9 as of this PR) .... maybe we should distinguish between "lower" and and "upper" bound python test versions, so that we do not need to do the variables/files rename exercise again in the future

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla-signed [bot] added once the contributor has signed the CLA
Projects
Status: 🆕 New
Development

Successfully merging this pull request may close these issues.

4 participants