Open MattF-NSIDC opened 11 months ago
Perhaps instead of the "Do nothing" step, a boolean flag could enable the bot to post "Your lockfile looks great! Nothing to do."
Hi @MattF-NSIDC, thanks for chipping in! I'd like to preface this by saying that I was planning to move towards an automatic no-prompting solution given permissions issues when working with PRs from forks (see https://github.com/CryoInTheCloud/hub-image/pull/88#issuecomment-1718270480). This would be similar to linters like pre-commit-ci that automatically commit changed files, when it detects that certain files need updating.
That said, I really like your idea on having a bot comment on whether a lockfile update is needed. This would be a form of feedback, similar to what Jessica requested in https://github.com/CryoInTheCloud/hub-image/issues/48 on requiring /condalock
to pass before a PR can be merged (i.e. have the /condalock
run in the 'Checks' tab). Your idea is akin to what conda-forge is doing with https://conda-forge.org/docs/maintainer/infrastructure.html#admin-web-services. Specifically, they have a conda-forge-linter
bot checking that the files are ok, and users would use a command like @conda-forge-admin please rerender
to update the files automatically (see e.g. https://github.com/conda-forge/icepyx-feedstock/pull/9).
Note that all this logic might actually need to be implemented over at https://github.com/weiji14/conda-lock-refresh-demo (trying to keep this conda-lock-refresh
GitHub Action as close to the original conda-lock CLI as possible, with extra logic on the checks/triggers elsewhere). I'll keep an eye on the 'validate' feature over at conda-lock
and we can work on this together later.
Your idea is akin to what conda-forge is doing with https://conda-forge.org/docs/maintainer/infrastructure.html#admin-web-services. Specifically, they have a
conda-forge-linter
bot checking that the files are ok, and users would use a command like@conda-forge-admin please rerender
to update the files automatically (see e.g. https://github.com/conda-forge/icepyx-feedstock/pull/9).
This was my inspiration :) I like this approach because it avoids pushing things to my working branch without my consent. I don't like getting confused because of a bot surprise pushing to my branch while I'm working.
I'll keep an eye on the 'validate' feature over at conda-lock and we can work on this together later.
Excited to chat more :)
EDIT: In quoting by copy-paste I think I accidentally sent a notification out to @conda-forge-admin
. Sorry, please ignore :)
Hey @weiji14, love this :) I've been thinking about making something like this, maybe we can work together!
What I'm looking to achieve with a conda-lock action is a workflow that not only provides a slash command like
/condalock
like this one does, but also notifies contributors when it's needed. Because not all changes impact the environment source fileenvironment.yml
, and even changes that do may not require another lock. For example:Currently, this isn't very feasible because there's no way to validate a lock file agrees with its sources without also potentially triggering a solve, so doing a check like this would be slow, not real-time-ish like we'd want from a chat bot. I'm working on adding a new "validate" command to conda-lock that will enable users to select one or both of these checks:
conda-lock.yml
compatible with the specification in the source file e.g.environment.yml
? i.e. are the input sources still compatible with the lock?conda-lock.yml
includescontent_hash
es of its input sources; do those still match the input sources? i.e. are the input sources exactly the same?Both of these checks can be done really fast, but the former seems more useful than the latter. You can make changes to an
environment.yml
that make it logically the same but not identical.Discussion on this feature proposal here: https://github.com/conda/conda-lock/issues/479