Deployment Secrets + Vision

NOAA-GFDL / fre-cli

Python-based command line interface for FRE (FMS Runtime Environment) to compile and run FMS-based models and post-process their output.

GNU Lesser General Public License v3.0

3 stars 7 forks source link

Deployment Secrets + Vision #19

Closed bcc2761 closed 1 month ago

bcc2761 commented 7 months ago

~Workflow script uses $ANACONDA_USERNAME and $ANACONDA_PASSWORD GitHub secrets; ideally this should be the GFDL Channel's login info, but Chris or my login info may be stored for use for the time being.~

In regards to when the action is run, it is set right now to be called on PR (closed, opened, etc.).

However, there is an issue regarding versions. If the current version is not being changed (i.e. 0.1.0 to 0.1.1), the current existing package in the Anaconda cloud gets removed and nothing is uploaded.

Additionally, the end goal is to move the deployment out of this repo itself, and into the GFDL conda-recipes repo...

ceblanton commented 7 months ago

ANACONDA_USERNAME and ANACONDA_PASSWORD repository secrets are added. How do we check that they work?

bcc2761 commented 7 months ago

@ceblanton we can run the GitHub action, right now it is set to call on PR

bcc2761 commented 7 months ago

GFDL Channel issue resolved, fixed with token
Version control needs to be added
Chris suggests:
1. Conda publish action to be triggered upon pushes to main branch only (done)
2. New Conda build action file to be triggered upon pull request for testing
3. Deployment upon tagged releases

bcc2761 commented 6 months ago

Update 2/26:

now able to publish conda package of same version number with workflow if there is an existing one and it doesn't remove the existing package without uploading a new one
however, we still want a simpler way to change version number, maybe a click command for user, since the attempts at using GIT TAG were unsuccessful
Chris suggests a cronjob in the future to automatically renew the CLI package in the Anaconda cloud every morning

bcc2761 commented 4 months ago

Update 4/16:

The cronjob was working for a while, until suddenly #75 arose with conda installation errors. In the case of the cronjob, conda install fre-cli keeps installing an older version (fre-cli 0.1.2) instead of fre-cli 0.1.4. The cause of this issue remains unknown, but this issue does not occur on Gaea with a personal conda (version 24.1), or on lscamd50-d (AMD dev box, conda version 23). Source of issue my be incompatible dependencies/packages, but this is only my guess. May really just be a conda version issue

ilaflott commented 2 months ago

@ceblanton whats the status of this when you get a chance?

bcc2761 commented 2 months ago

@ilaflott as of changing from module load conda to module load miniforge (which uses newer conda version 24.something instead of 4.something), this has been solved. The latest version is now installed, but there is a persisting issue relating to the scrontab to daily install when the version number isn't changed despite code changes. I was trying to find a solution for this for a long time but never succeeded in finding a way to grab a $GIT_TAG and incorporate it as the meta.yaml's conda package version number

ilaflott commented 1 month ago

solved according to @bcc2761, $GIT_TAG aspects are being addressed in versioning issues/PRs