`launch-mapdl-docker` action??

[germa89]

Should this action be moved to this repo??

https://github.com/ansys/pymapdl/tree/main/.github/actions/launch-mapdl-docker

I developed this action to simplify MAPDL docker image usage, but I got some rejection because its dependency of pymapdl.

Reference: ansys/pymaterials-manager#473

[RobPasMue]

Maybe make it part of PyMAPDL as it is currently? Or as a separate repo? PyDPF follows this approach as well

[moe-ad]

While my immediate thought was "why not"? I do wonder how centralizing such an action is going to play out in the long run with respect to maintenance. For example:

• I am not super familiar with MAPDL/PyMAPDL to understand/know all of the "undocumented" knowledge like you have, so it might be silly to just take on the maintenance burden for something we can't effectively support if something breaks.
• It blurs the line on what can be shipped by Ansys Actions. The launch-mapdl-docker action looks like something that should stay a reusable PyMAPDL workflow. If other projects do not want to depend on it directly, they should keep maintaining their own custom solution for launching MAPDL on docker.
• It adds a lot of extra bells and whistles that we typically try to avoid, like javascript.

Having said that, I am open to us exploring ways in which Ansys Actions can provide the ecosystem with a way to centrally ship actions that might be useful for multiple projects, but there has to be an explicit contract that we do not maintain them (or we maintain as best as we can). For example:

_ecosystem-actions/
├── launch-mapdl-docker/
│ └── action.yml
├── xxx-action/
│ └── action.yml
├

Then a project could call ansys/actions/_ecosytem-actions/launch-mapdl-docker and it will be understood that all such actions are "experimental".

[Andy-Grigg]

I think there are two different types of 'non-ansys/actions' which are commonly used across repos:

• Public actions, like this 'launch-mapdl-docker' action. Other people can just pick it up and use it and will get significant benefit from it. It's likely to be used broadly, at least within PyAnsys repos, beyond teams that the maintainers interact with directly
• Private actions, like one we use for managing VM state within PyGranta repos. These are very niche, not very usable for other teams, very specific to the PyGranta environment. Even if we did make it available in a more public way, it's unlikely it's going to get broad use.

I think for the public ones, putting it somewhere centralized makes sense. 'ecosystem-actions' or 'contributed-actions' makes sense, either as a subdirectory in ansys/actions, or in a separate repo. But a separate repo for all contributed actions, so there's one place to go to see if it exists.

For the private ones, these would continue to be used directly from 'other' repos.

The main things I think we'd gain are visibility (maybe if you add something to the ecosystem-actions you have to provide docs to go along with it?) and some sense of consistency across these actions.

[RobPasMue]

But a separate repo for all contributed actions, so there's one place to go to see if it exists.

I like this idea TBH! A separate repo were we could drop all our product-specific/project-specific actions.. while keeping them separated from the rest of the transversal, multipurpose actions we have here

[germa89]

This...

I think for the public ones, putting it somewhere centralized makes sense. 'ecosystem-actions' or 'contributed-actions' makes sense, either as a subdirectory in ansys/actions, or in a separate repo. But a separate repo for all contributed actions, so there's one place to go to see if it exists.

while it makes sense, it goes against this:

I am not super familiar with MAPDL/PyMAPDL to understand/know all of the "undocumented" knowledge like you have, so it might be silly to just take on the maintenance burden for something we can't effectively support if something breaks.

Grouping together a bunch of different actions will require a strong commitment from the developers or a good maintainer that ping them (or fix their issues), and I am not sure it will work well for this kind of repo (frequent development, but not on a daily basis). I would prefer to not go for this approach.

From my point of view, it is either:

• Option A: part of ansys/actions where we have excellent people managing actions used by everyone (so they can ping the right person if something fails, or kick out actions that are not maintained anymore).
• Option B: we keep it under the umbrella of each library maintainer wether that is part of the same repo (Option B1), or a different one (Option B2); I have no strong opinions. Same repo means easier discoverability and maintenance. Different once makes the action more light-way.