Docker autogenstudio

[r3d91ll]

I updated the Dockerfile.full, and Dockerfile.base with autostarts for AutogenStudio. I figured there would probably be a lot of attention on this project. Now that we have an excellent front end, we might as well make it a seamless setup.

Why are these changes needed?

Easy setup for Autogen Studio

Related issue number

#1172 #1241

Checks

• [ X] I've included any doc changes needed for https://microsoft.github.io/autogen/. See https://microsoft.github.io/autogen/docs/Contribute#documentation to build and test documentation locally.
• [ ] I've added tests (if relevant) corresponding to the changes introduced in this PR.
• [X ] I've made sure all auto checks have passed.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (135bca4) 32.11% compared to head (8660ede) 32.08%. Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1275      +/-   ##
==========================================
- Coverage   32.11%   32.08%   -0.03%     
==========================================
  Files          32       32              
  Lines        4391     4394       +3     
  Branches     1024     1025       +1     
==========================================
  Hits         1410     1410              
- Misses       2865     2867       +2     
- Partials      116      117       +1     

Flag	Coverage Δ
unittests	32.04% <ø> (-0.03%)	:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[qingyun-wu]

Why the file start-docs-server.sh is added to the website folder?

[qingyun-wu]

And I believe these two PRs should coordinate? Both are trying to add docker for autogenstudio. @victordibia @gagb

[gagb]

@r3d91ll before I review your PR what do you think about: https://github.com/microsoft/autogen/issues/1286

[r3d91ll]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

[gagb]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

[r3d91ll]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this.

If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community.

Best regards

[gagb]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this.

If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community.

Best regards

I agree with the importance of this @r3d91ll! I will submit a PR tomorrow morning and add you as a reviewer :)

[gagb]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early next week. Given the critical nature of ensuring a smooth development process and the importance of avoiding the pitfalls associated with developing as root – a topic I'm quite passionate about, as evidenced by my recent pull request (#1251) – it might be more pragmatic for you to take the lead on this. If you're able to address it before Sunday, I will certainly make time to review it then. Otherwise, I plan to tackle it early next week. Our collective focus on providing clear guidance and maintaining best practices for our developers is paramount, especially in the context of developing as root and the risks that poses to our community. Best regards

I agree with the importance of this @r3d91ll! I will submit a PR tomorrow morning and add you as a reviewer :)

@r3d91ll here is the PR https://github.com/microsoft/autogen/pull/1333

[r3d91ll]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

Thank you for the kind words! Would you like to draft it and I can very quickly review it?

Thank you for the consideration, but unfortunately, I will not have the time to give this the attention it deserves until early sometime next week. It might be more pragmatic for you to take the lead on this. My day job is pretty all-consuming at the moment and I can only spare time on my weekends.

If you can address it before Monday, I will certainly make time to review it then. Otherwise, I plan to tackle it sometime Monday or Tuesday at the earliest.

Best regards

[gagb]

@r3d91ll the other PR was merged, please feel free to suggest changes per your this PR: https://github.com/microsoft/autogen/pull/1333

[KierenB]

FWIW I think that this PR could be improved by adding something about data/config persistence. As it stands any customisation a new user does will be lost when the container restarts. Maybe add something around volume mappings? Otherwise this is awesome and it does "just work" - nice work @r3d91ll

[sonichi]

@gagb @victordibia checking in here.

[gagb]

@r3d91ll before I review your PR what do you think about: #1286

I'm in full support of it. I didn't have the time to track down why the Dockerfile.dev had a package conflict. Your solution is elegant as it solves the local build issue I saw as well as the codespaces issue you found. We just need to make sure that users know to look in the .devcontainers. I'm willing to draft this for now or close in lieu of your pull.

@r3d91ll the new dev containers were merged some time ago. Do you still want the changes you proposed in this PR?

[gagb]

@r3d91ll I am closing this PR. Please re-open if you need these changes.