You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In our use case we would prefer to use specific Az module versions, as opposed to whatever is available on the agent. Relying on specific agent version is not ideal either, as those are not granular enough to "care" about Az modules.
Using azPSVersion parameter works, but introduces a rather long delay (2+ minutes), as modules of specific version need to be installed, examples:
Fig. 1: Job execution time depending on runner agent and azPSVersion value
Fig. 2: Same as above, executed 5 minutes later (notice the rather large difference).
I understand that this is mostly due to the large number of Az modules and relying on PowerShell Gallery (which is known to be slow at times).
Based on that we can define 2 pain points:
having to install all 90+ Az modules at a time
=> possible action: limiting installation to specific modules, based on action input (this would be for advanced users that are fully aware of what modules they depend on)
relying on public PowerShell Gallery that has performance issues at times
=> possible action: allowing to cache and reuse module files (something like this)
Do let me know if those 2 action points above sound ridiculous or not.
The text was updated successfully, but these errors were encountered:
In our use case we would prefer to use specific Az module versions, as opposed to whatever is available on the agent. Relying on specific agent version is not ideal either, as those are not granular enough to "care" about Az modules.
Using
azPSVersion
parameter works, but introduces a rather long delay (2+ minutes), as modules of specific version need to be installed, examples:Fig. 1: Job execution time depending on runner agent and
azPSVersion
valueFig. 2: Same as above, executed 5 minutes later (notice the rather large difference).
I understand that this is mostly due to the large number of Az modules and relying on PowerShell Gallery (which is known to be slow at times).
Based on that we can define 2 pain points:
=> possible action: limiting installation to specific modules, based on action input (this would be for advanced users that are fully aware of what modules they depend on)
=> possible action: allowing to cache and reuse module files (something like this)
Do let me know if those 2 action points above sound ridiculous or not.
The text was updated successfully, but these errors were encountered: