Run update.sh in GH Action on upstream version bump about micromamba-docker HOT 14 CLOSED

I implemented this, but GitHub Actions are currently degraded, so I can't even do the limited testing I was hoping to do. I will leave this issue open until we successfully process a micromamba release on the new configuration.

from micromamba-docker.

Using digests in FROM lines is a docker best practice and not specific to micromamba-docker.

Getting this completely automated is a bit tricky. I believe it would involve me turning off branch-protection.

There is an easy solution with less automation:

1. Remove calls to check_version.py in the CI and CD workflows
2. No longer pass the VERSION build-args in the CD workflow
3. Remove the 6-hour schedule for running the CD workflow

A person would then have to run update.sh after a release, generate a PR, and get the result merged to main before dockerhub will get a new build.

It would be easy to add back some automation to generate the PR with the update.sh commit when new versions of micromamba arrive on conda-forge.

from micromamba-docker.

That's a really interesting thought. Doing it manually could make a lot of sense short-term.

There's also a decent chance that in some months I'll have set up something similar for on something less critical, and may have more concrete ideas.

With your last sentence, do you mean that instead of pushing in CD we could trigger a PR à la regro/cf-autotick-bot? That would be really cool.

from micromamba-docker.

I'm not familiar with regro/cf-autotick-bot, but here is the somewhat reduced automation I am envisioning:

1. Create a new GitHub Actions workflow 'Create_update_PR', which runs a workflow on a 6 hour schedule. It runs check_version.py and if a new version of micromamba is found on conda-forge, then it will:
   1. create a new branch named update_to_$VERSION
   2. run update.sh
   3. generate a commit
   4. push commit
   5. generate a PR
2. I manually merge these PRs after they pass CI.
3. Merge of PR starts build and push to dockerhub.

(sorry for all the edits)

from micromamba-docker.

Yes, that's exactly what I meant. You seem to have very nicely broken down all the individual steps.

from micromamba-docker.

That's very exciting. Not that I'm very experienced, but I read through it, and it looks good to me. I'm looking forward to seeing what it does.

from micromamba-docker.

Micromamba 0.21.0 is out!
https://github.com/mamba-org/mamba/releases/tag/2022.02.07

from micromamba-docker.

@wholtz, I just realized, do we have a mechanism to ensure that only one PR at a time is made, or will a new PR be opened every 6 hours?

from micromamba-docker.

Just found this in the docs for the PR action:

If a pull request already exists and there are no further changes (i.e. no diff with the current pull request branch) then the action exits silently.

So if I'm reading that correctly I think it'll be fine. Sorry for the noise!

from micromamba-docker.

I let the cronjob kick off the initial PR generation and then manually triggered the workflow again. The second invocation didn't leave any trace.

But the initial PR did not automatically trigger the CI workflow. I had to disable branch protection to continue the process. This seems to happen most times that I update .github/workflows/test.yaml and likely it will be fine for the next PR.

from micromamba-docker.

Looks like not triggering the CI is a known issue with various possible workarounds.

from micromamba-docker.

I'll look into implementing one of those workarounds....

from micromamba-docker.

The workarounds that would result in the automatically generated PR kicking off the CI workflow are all messy. So I'm going to stick with the simple but slightly less automated solution:

Use the default GITHUB_TOKEN and allow the action to create pull requests that have no checks enabled. Manually close pull requests and immediately reopen them. This will enable on: pull_request workflows to run and be added as checks.

The workflow will be:

1. PR is automatically generated
2. I will then close the PR
3. I will immediately re-open the PR
4. wait for CI workflow to complete
5. Click 'Merge' button

The only small downside of this is that I have to sit and wait for CI to run.

from micromamba-docker.

@wholtz, makes sense given the tradeoffs. Thanks for getting that straightened out!

If you want to reduce distraction from watching the tests, perhaps you could add a Slack (or similar messaging client) webhook to the end of your CI workflow, conditioned on the PR coming from the bot. Ah, but the tests are taking less than for minutes.

from micromamba-docker.