test: mamba and micromamba release candidates

[jjerphan]

No description provided.

[mathbunnyru]

@jjerphan maybe you would like to make a contribution to this repo?
I recently changed the rules and workflows will run automatically for non first-time contributors (without having me to allow to run PRs): #2202 (comment)

The contribution you could make is to be able to specify mamba version as ARG (more or less in the spirit of this PR, but a bit more general):

1. if default, behaves exactly like our current main branch
2. if something-else: pin is added
3. if rc in name, conda-forge/label/mamba_prerelease is added during installation

Would allow to test release candidates/previous versions with one line change.
And it would allow to install custom mamba versions in forks (I don't know if anyone needs it, though).

[jjerphan]

I do not want to make a contribution to this repository, I mainly want to test that the next release is not going to break docker-stacks.

Nevertheless your proposition might help such checks in the future.

[mathbunnyru]

I completely understand the this PR is not to be merged and just to test the new rc, just wanted to have a better process in the future, yes

[jjerphan]

I am not against your proposal but I am being quite conservative: if we introduce an argument for the version of mamba, it implicitly comes with an API contract and extra maintenance for something users might not have requested and might not need; hence potentially extra maintenance costs for no benefits.

I think simply reopening this PR and adapting the version number when needed is sufficient; but feel free to implement this change (extracting part of the diff of this PR if needed).

[mathbunnyru]

I am not against your proposal but I am being quite conservative: if we introduce an argument for the version of mamba, it implicitly comes with an API contract and extra maintenance for something users might not have requested and might not need; hence potentially extra maintenance costs for no benefits.

Ok, I understand your point.

I think simply reopening this PR and adapting the version number when needed is sufficient; but feel free to implement this change (extracting part of the diff of this PR if needed).

Still makes me hit "Allow CI to run" button though after every commit (as I tried to explain in the very beginning), and completely defeats my proposal.

[mathbunnyru]

No worries at all, just wanted to make both your and my life a tiny bit easier in the future.

[jjerphan]

Still makes me hit "Allow CI to run" button though after every commit (as I explained in the very beginning), and completely defeats my proposal.

Oh yes, I forgot this. I can make another small contribution in this regards.

[mathbunnyru]

Still makes me hit "Allow CI to run" button though after every commit (as I explained in the very beginning), and completely defeats my proposal.

Oh yes, I forgot this. I can make another small contribution in this regards.

Yes, would be highly appreciated. That was the whole point 🙂

[jjerphan]

My mind was elsewhere.

I can have a look at a simple thing (like #2187) soon.

[mathbunnyru]

My mind was elsewhere.

I can have a look at a simple thing (like #2187) soon.

Thanks @jjerphan!

That might be a bit tricky because after all we haven't decided to have it or not.

Maybe fix some typo or clarify any statement in docs, doesn't have to be anything important, to be honest.
Or, even simpler: update changelog repo with PR you like in the past 4 days 🙂
https://github.com/jupyter/docker-stacks/blob/main/CHANGELOG.md

This one is good enough: #2238

[jjerphan]

See #2244.