Add: Autostart by rtmiz · Pull Request #132 · 2i2c-org/jupyterhub-fancy-profiles

rtmiz · 2025-07-15T08:26:54Z

Consolidation of Build and Start buttons in the custom image building UI into one button.

Permalinks now feature a autoStart field, that when set to true will instantly initiate the spawning process of the given environment.

batpad · 2025-07-15T09:02:50Z

@GeraldIr this looks good to me!

Do you mind writing up a couple sentences on what this solves and exactly what the expected behaviour here would be? And then am happy to test.

It would also be nice to figure out writing a test for this - I can help with that once we have this outlined a bit.

Thank you for your contribution!

rtmiz · 2025-07-15T09:44:52Z

I've found the workflow of Build Image -> Start Image a bit cumbersome, so I was just looking for a way to simplify it down to a single press of a button.

Ultimately I'd like to add an auto-start option for permalinks as well, in order to go from Click Permalink -> Running JupyterLab in a single click from anywhere without further user-input.

This is a feature for the original BinderHub UI so that's what I'm trying to replicate.

To be honest, I mistakenly opened the PR early, so for now I'll change this to a draft.

batpad · 2025-07-15T09:49:01Z

@GeraldIr haha no worries - and yes, automatically starting the server once the image builds sounds really good to me and happy to help how I can to get this merged.

For auto-starting on the Permalinks, let me open a separate ticket as well. In principle, this seems really nice - I think my only concern is if there's any security considerations to worry about - i.e. user clicks link and starts a server with a malicious image, etc. - the current way at least there is a bit of a confirmation step. Not sure how much of a concern this is as something we should worry about.

Thanks again for jumping into this!

rtmiz · 2025-07-15T15:00:55Z

I've included auto-start (build and start) from permalinks now.

To trigger this, include the "autoStart":"true" in the Permalink values.

I'll still need to include some tests, as well as hiding the Start button when the Build and Start Button is visible for the ImageBuilder (just confusing to have the vestigial button remain).

rtmiz · 2025-07-15T15:03:08Z

As for the security concerns, as the standalone binderhub UI already works the same way I don't see much of an issue with this;

but I am not a cybersecurity expert and usually take such concerns too lightly, so there is that 😅

rtmiz · 2025-10-01T11:46:10Z

I've now consolidated the Build and Start buttons from the custom image builder into a single button, as well as made it easier to create auto-starting permalinks, by including the autoStart option set to false by default when copying a permalink.

batpad · 2025-10-01T11:56:09Z

@rtmiz 🙌 thank for you for this!

I'll spend some time testing this tomorrow, but I will need to find some help to do a proper review as this does touch a fair bit of things.

Could you add a short note, either to this PR or somewhere in the docs / code (I need to do a proper overhaul of the docs soon, so you can drop it here and I can use the text when I do the overhaul is fine) that:

Says a bit about the rationale for this feature (what you outlined above makes perfect sense to me!)
Gives precise instructions on how to test this and what expected behaviour is

I'll give this a whirl this week and let you know any feedback around usability, and then try and find someone who is able to do a proper frontend review - but in general, this is looking good to me, ty!

batpad · 2025-10-01T12:02:07Z

cc @wildintellect @maxrjones - getting y'all's eyes on this: I think I might have seen you ask for something similar - would be good to get a 👍 from y'all on the general idea behind the feature and validating the usefulness would help me prioritize getting this merged.

rtmiz · 2025-10-01T12:13:33Z

@batpad

Of course, here's my rationale:

I wanted to simplify the user experience down from 2 separate button clicks to 1. Previously the custom image building UI featured a "Build"-button, which built and pushed the image and then a "Start"-button, which initiated the spawning process of the previously built image. I couldn't think of a real use-case in which starting didn't follow building every time, so I merged the buttons.

As for the auto-start feature, this is something we were looking for in our deployment and have now used to great success. We combined the autoStart option with multiple ?next= referrals (for login as well as invoking nbgitpuller) to cut down the workflow for users. This basically allowed us to generate URLs which are a 1-click referral to a specific environment with a specific notebook and it's been a great boon for tutorial sessions and our notebook gallery. Copied permalinks also now include a "autoStart": "false" by default, to make generating autoStart URLs easier.

As for testing:

Both features should be rather straightforward to test behavior on.

The Start button should change to a Build and Start button only when the custom image building profile is selected.
And upon clicking (submitting the form) initiate the spawn process of the built image after building is complete.
The autoStart permalink-option (when set to "true") should immediately submit the form after filling out the given values in the permalink, such that no further interaction from the user is needed when clicking the URL (if logged in and not having a running server).
The permalink button should now append a "autoStart": "false" option onto permalinks.

batpad · 2025-10-01T12:25:05Z

As for the auto-start feature, this is something we were looking for in our deployment and have now used to great success. We combined the autoStart option with multiple ?next= referrals (for login as well as invoking nbgitpuller) to cut down the workflow for users. This basically allowed us to generate URLs which are a 1-click referral to a specific environment with a specific notebook and it's been a great boon for tutorial sessions and our notebook gallery. Copied permalinks also now include a "autoStart": "false" by default, to make generating autoStart URLs easier.

That sounds super-cool! If you have anything public that you're able to share, I'd love to get a better sense of how y'all are using this.

rtmiz · 2025-10-01T13:43:06Z

@batpad You can find our notebook gallery here: https://eopf-sample-service.github.io/eopf-sample-notebooks/gallery/

From there select a notebook and click the Launch in JupyterHub button! You'll need to create an account though to use it, but otherwise it should be accessible.

Also, there seems to still be some issues related to permalinks (values don't get updated if you opened the page via one and autoStart doesn't work yet for the build image page). I'm working on these right now.

I can also share a piece of code when these issues are fixed that generates these URLs, this would also be of interest to @maxrjones for his second issue #137

rtmiz · 2025-10-01T16:00:02Z

To fix the issue I added a timeout when auto-starting so the form can properly load (this is a hack imo, but I don't know enough about react to fix this in a proper manner).

@maxrjones Here's the code I mentioned earlier, make sure the image you are building will have nbgitpuller installed:

import urllib.parse
import re

# Change these values

# full url from github to the relevant ipynb, e.g.: https://github.com/org/repo/blob/branch/notebooks/example.ipynb
notebook_url = "https://github.com/org/repo/blob/branch/notebooks/example.ipynb"

# permalink copied from filled out fancy profiles form, this can be from the build your own image UI
permalink = ""

# JupyterHub URL e.g.: https://hub.example.org
jupyterhub_url = "https://hub.example.org

# URL creation
notebook_suburl = notebook_url.split("/blob/")[0].split("/")[-1] + "/" + "/".join(notebook_url.split("/blob/")[1].split("/")[1:])
branch = notebook_url.split("/blob/")[1].split("/")[0]
git_repo_url = notebook_url.split("/blob/")[0]
gitpull_next = f"/hub/user-redirect/git-pull?repo={git_repo_url}&branch={branch}&urlpath=lab/tree/{notebook_suburl}"
spawn_next = '/hub/spawn?next=' + urllib.parse.quote(gitpull_next, safe='')
occ = re.search("%23.+?(?=%7D)", permalink)
fancy_forms_config = occ[0].replace("%22autoStart%22%3A%22false%22", "%22autoStart%22%3A%22true%22") # Make sure autoStart is set to true (you can comment this out if it's not important)
finished_url = f'{jupyterhub_url}/hub/login?next=' + urllib.parse.quote(spawn_next, safe='') + fancy_forms_config + "%7D"

print(finished_url)

colliand · 2025-10-01T16:31:58Z

I'd love for 2i2c to celebrate this work in a blog post. I invite @rtmiz and/or @batpad to share some quick information using this issue template. I thank my colleague @choldgraf for helping to make wins like this more visible to a wider audience.

rtmiz · 2025-10-15T15:44:02Z

@yuvipanda The tests/linting now pass locally.

rtmiz · 2025-10-28T13:03:48Z

@colliand I've posted the blog entry here: 2i2c-org/2i2c-org.github.io#527

colliand · 2025-10-28T15:14:21Z

Thank you @rtmiz !

batpad · 2025-10-29T16:22:16Z

@rtmiz sorry for the non-responsiveness here. Am really trying to get #122 properly tested and merged before picking this one up. We made a bit of progress testing that PR today so hopefully I can do this this week and start looking at merging this PR.

Apologies again.

rtmiz · 2025-11-03T08:50:47Z

@batpad No worries!

batpad · 2025-11-18T04:56:44Z

src/ProfileForm.tsx

+      if (form) {
+        const button = form.querySelector("button[type=\"submit\"]") as HTMLButtonElement | null;
+        if (button) {
+          setTimeout(() => {


This seems like a neat hack indeed. Would just be curious to see if there's some-how a better way to do this, this does seem like it could get brittle and hard to debug in some edge case scenarios.

Echoing @batpad 's concern - there are two ways of submitting the form in this file. Any reason of not using requestSubmit (https://github.com/2i2c-org/jupyterhub-fancy-profiles/pull/132/files) for this case?

batpad · 2025-11-18T05:03:48Z

The code looks good to me and I think we should do a bit of testing and merge this in.

@hanbyul-here would you be able to help with getting this over the line:

Test everything works as per testing notes in Add: Autostart #132 (comment)
Give the code a thorough review: there's definitely a couple things in there that seem a bit awkward - I can totally see why they're there and I don't have any better ideas than what's there, but hoping @hanbyul-here you may have some suggestions :-)
Review documentation to make changes / additions based on this feature being added. @rtmiz would you be able to rebase / merge the updated main which has some updated docs and maybe do a quick review and make any changes to include this feature?

Looking at the code and thinking about this a bit, I think we can get this in before #122 and don't need to wait.

Overall, this looks fine to me - in general, we need to fix the way Permalinks work, but that depends on upstream changes in Jupyterhub, so I do think we should go ahead with this and update docs to reflect this change.

batpad · 2025-11-18T05:07:55Z

src/ImageBuilder.test.tsx


-  renderWithContext(<ProfileForm />);
+  renderWithContext(
+    <form>


Needing to wrap the <form> around the <ProfileForm> in the tests makes sense to me - since fancy-profiles gets "injected" onto a page that already contains the container <form> tag, the <ProfileForm> expects to be rendered inside an existing <form> - since that does not exist during tests, we add it this way.

This looks a little awkward, but makes sense to me. Just giving @hanbyul-here some context while reviewing - not sure if there's a way to do this that feels more elegant, but this seems okay to me.

🤔 imo, it is ideal if the test's scope is narrowed enough that the test doesn't have to cover any unnecessary tasks. Most tests were scoped down well enough that it doesn't need additional wrapper. I understand some tests might need this wrapper now since this PR makes form submission this application's responsibility. but I still feel like we can get rid of this additional wrapper for the ones that don't need one?

I think one of the biggest change this PR introduces is the programatic form submission -
There’s something nice about letting HTML handle form submission — it keeps the application’s responsibility focused on processing and cleaning the data. This PR expands that responsibility. That’s not necessarily a bad thing, but we would at least need a test for it.
Maybe we can add an explicit test to check if form submission worked with this additional wrapper?

…false to copied permalink to make creating auto-start urls easier

…stency.

…r full auto-start (login->profile-selection->notebook) configuration

rtmiz · 2025-11-18T13:13:41Z

@batpad I've rebased the changes from main and added the documentation for the feature to the existing myst pages.

I've also included the code-snippet that I've posted above for nbgitpuller integration and handling login via URLs, I thought it might be a nice addition to complement this feature.

batpad · 2025-12-04T11:40:22Z

@rtmiz I took the liberty of doing a merge with the latest main that includes the changes for token-based auth to the Binder backend.

(adds this bit to ImageBuilder.tsx : https://github.com/2i2c-org/jupyterhub-fancy-profiles/blob/main/src/ImageBuilder.tsx#L11 )

Apologies again for the long wait - if @hanbyul-here has no comments, I think we should merge this soon. Thanks again!

hanbyul-here

I am still getting myself familiar with the codebase but I thought it would be better to start the conversation early rather than hang up. So please bear with me if I read anything wrong.

hanbyul-here · 2025-12-04T15:42:40Z

src/ProfileForm.tsx

+      if (form) {
+        const button = form.querySelector("button[type=\"submit\"]") as HTMLButtonElement | null;
+        if (button) {
+          setTimeout(() => {


Echoing @batpad 's concern - there are two ways of submitting the form in this file. Any reason of not using requestSubmit (https://github.com/2i2c-org/jupyterhub-fancy-profiles/pull/132/files) for this case?

hanbyul-here · 2025-12-04T15:44:54Z

src/ProfileForm.tsx

        onClick={handleSubmit}
      >
-        Start
+        { buildImageStart ? "Build Image and Start" : "Start" }


This doesn't get synced with the user's current choice - When I toggle back to one of the default options, the button still says 'Build Image and Start' (and will start the server with custom image instead of one of the default options that I selected)

If I am reading the flow correctly, there is no way to prevent a user from hitting submit multiple times while the image is building, and there is no 'check' to see if the image building is already in progress. I am concerned that this will result in multiple build triggers.

Unsure what you mean by this not syncing with the user's current choice? This is how it looks on my end.

As for the multi-submit, you are right, there is currently nothing stopping the user from either submitting the form again or changing to a different drop-down item during the build process. I'll see to it that the form gets disabled during building.

re:Syncing user's choice: Ah! I forgot that dev environment is different per config. My config (default config that comes with the app) has more than one profile, so user can navigate between profiles. (There is a case where ImageBuilder is not unmounted yet, while a user's current choice is not building a custom image, which leaves the text on the button unsync) Is this very unlikely configuration set up in real life?

state-unsync.mov

Ahh, I see, I can replicate this on one of my deployments! I'll see if I can find a fix for this.

This should be fixed with my newest changes.

hanbyul-here · 2025-12-04T16:24:48Z

src/ProfileForm.tsx

+    if (buildImageStart){
+      await buildImageStart();
+    }
+    setShouldSubmit(true);


I might be missing something but I can't figure out why this needs to be handled indirectly. Can we directly call form.requestSubmithere?

Nope, you're right I've changed both this and the other occurrence to form.requestSubmit()

I actually take this back, I didn't test it properly, using form.requestSubmit in either of these circumstances does not work for reasons unknown to me (but presumably the reason I have it in there how it is, it's been a while now).

I agree that there should be a neater way of doing all of this, but I've ended up with what works over what seems like it should work here

hanbyul-here · 2025-12-08T16:12:25Z

src/ImageBuilder.tsx

+    return () => {
+      setBuildImageStart(null);
+    };
+  }, []);


I am guessing a lot of added useRefs are to get updated values for handleBuildStart. I wonder if we can trigger the this hook with those values that need to be updated? (moving dependencies of this hook https://github.com/2i2c-org/jupyterhub-fancy-profiles/pull/132/files#diff-fa607bb96a32d3e9d15c039c5b36fa3806089f0a0023d231194f996ec3fea311R205 to here?)

src/ProfileForm.tsx

src/ImageBuilder.tsx

hanbyul-here · 2025-12-08T20:29:21Z

src/ProfileForm.tsx

+    const form = document.querySelector("form");
+
+
    const formIsValid = form.checkValidity();


Shouldn't form validation happen before building image?

This is before building no? It's in the extra submitTheForm Function (arguably a bad function name), but we aren't building here yet, we're just doing manual form validation.

Isn't the flow (from https://github.com/2i2c-org/jupyterhub-fancy-profiles/pull/132/files#diff-57e82f51ce2ff82498b68631c62c2bf5723ee306d5f89d5a4728012f0ae999e4R52-R56)
buildImage if there is one => and display the form errors (submitTheForm but not blocking form submit) => Submit ? Which means that even if Repository input is not valid, it will start the buildimage (even if it errors)

This behavior is also related to this comment https://github.com/2i2c-org/jupyterhub-fancy-profiles/pull/132/files#r2632003823

I've reworked the flow now, if you could check it out again.

hanbyul-here · 2025-12-08T21:23:37Z

src/ImageBuilder.test.tsx


-  renderWithContext(<ProfileForm />);
+  renderWithContext(
+    <form>


🤔 imo, it is ideal if the test's scope is narrowed enough that the test doesn't have to cover any unnecessary tasks. Most tests were scoped down well enough that it doesn't need additional wrapper. I understand some tests might need this wrapper now since this PR makes form submission this application's responsibility. but I still feel like we can get rid of this additional wrapper for the ones that don't need one?

I think one of the biggest change this PR introduces is the programatic form submission -
There’s something nice about letting HTML handle form submission — it keeps the application’s responsibility focused on processing and cleaning the data. This PR expands that responsibility. That’s not necessarily a bad thing, but we would at least need a test for it.
Maybe we can add an explicit test to check if form submission worked with this additional wrapper?

…r methods

hanbyul-here · 2025-12-10T20:32:20Z

src/ProfileForm.tsx

      }, 100);

      setProfileError(!selectedProfile ? "Select a container profile" : "");
-      e.preventDefault();


This line was preventing the invalid form from being submitted, but now the form can be submitted with invalid values.

I am not sure if I missed something, but this is still not resolved as far as I can test. ex. I can put an invalid docker image (not binder image), but still can trigger the start of the server despite the error display.

This should be fixed with my newest update.

rtmiz · 2026-01-26T11:12:05Z

I've made some more updates as per @hanbyul-here 's suggestions and I think we can probably merge this soon @batpad .

Sorry for the delay from my end, with the holidays and some other work I didn't have much time for this.

rtmiz marked this pull request as draft July 15, 2025 09:44

rtmiz marked this pull request as ready for review October 1, 2025 11:44

rtmiz mentioned this pull request Oct 1, 2025

Authenticated Pre-filled Auto-Start Option #119

Closed

agoose77 mentioned this pull request Oct 13, 2025

[STRUDEL] New sharing-friendly workshop hub set up 2i2c-org/infrastructure#6617

Closed

10 tasks

batpad reviewed Nov 18, 2025

View reviewed changes

rtmiz added 5 commits November 18, 2025 13:25

Add: Autostart

b38a8a4

Add: auto-start via permalink

466e390

Updates: Consolidate build and start button into one, add autoStart: …

c9ba410

…false to copied permalink to make creating auto-start urls easier

Add: timeout when autoStarting so the form can properly load

a8d98fa

Fix: tests, linting. Wrap ProfileForm rendering in form tag for consi…

24cced1

…stency.

Fix: further linting issues

1378d38

rtmiz force-pushed the auto-start branch from 8894a60 to 1378d38 Compare November 18, 2025 12:26

Add: Documentation for Auto-Start feature, nbgitpuller integration fo…

edf25a2

…r full auto-start (login->profile-selection->notebook) configuration

rtmiz and others added 2 commits November 18, 2025 14:48

Add: reference to auto start and permalinks in the README.md

00c2f61

Merge branch 'main' into auto-start

ad794c6

hanbyul-here reviewed Dec 8, 2025

View reviewed changes

rtmiz added 3 commits December 9, 2025 15:30

Fix: failing tests, Update: use requestSubmit instead of varying othe…

5ebf70e

…r methods

Revert: last commit requestSubmit changes, uppercase AS in Dockerfile

7cbc138

Fix: autostart, Add: disable form during build

1a67522

hanbyul-here reviewed Dec 10, 2025

View reviewed changes

rtmiz added 2 commits December 18, 2025 11:53

Fix: state not syncing correctly, between different profiles

082f091

Update: relocate validation logic to change flow

2f0e792

		const form = document.querySelector("form");


		const formIsValid = form.checkValidity();

Conversation

rtmiz commented Jul 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

batpad commented Jul 15, 2025

Uh oh!

rtmiz commented Jul 15, 2025

Uh oh!

batpad commented Jul 15, 2025

Uh oh!

rtmiz commented Jul 15, 2025

Uh oh!

rtmiz commented Jul 15, 2025

Uh oh!

rtmiz commented Oct 1, 2025

Uh oh!

batpad commented Oct 1, 2025

Uh oh!

batpad commented Oct 1, 2025

Uh oh!

rtmiz commented Oct 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

batpad commented Oct 1, 2025

Uh oh!

rtmiz commented Oct 1, 2025

Uh oh!

rtmiz commented Oct 1, 2025

Uh oh!

colliand commented Oct 1, 2025

Uh oh!

rtmiz commented Oct 15, 2025

Uh oh!

rtmiz commented Oct 28, 2025

Uh oh!

colliand commented Oct 28, 2025

Uh oh!

batpad commented Oct 29, 2025

Uh oh!

rtmiz commented Nov 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

batpad commented Nov 18, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rtmiz commented Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

batpad commented Dec 4, 2025

Uh oh!

hanbyul-here left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

rtmiz commented Jul 15, 2025 •

edited

Loading

rtmiz commented Oct 1, 2025 •

edited

Loading

rtmiz commented Nov 18, 2025 •

edited

Loading

hanbyul-here Dec 10, 2025 •

edited

Loading

hanbyul-here Dec 18, 2025 •

edited

Loading

rtmiz commented Jan 26, 2026 •

edited

Loading