The release is the foundation of a one stop shop for our developer community to manage and monitor Forge apps. Next, even before we finish building out the ability to publish and sell Forge apps on Marketplace, you will be able to use the developer console to generate app install links that can be shared directly with administrators. This will be a lightweight way to distribute your app directly for testing and internal usage, similar to development mode for Connect–but streamlined! And later, we will add further functionality, including supporting observability of your Forge apps.
We want your feedback
As always, we are super interested in any feedback you can share on what has been built so far, and what would be most valuable for us to prioritise next. For example, what kind of observability are you craving for your apps, that you would like to see represented in the developer console?
there is a hint error here ‘Run installation-list in the forge CLI to see the instance IDs’
you actually need to run ‘install:list’ according to my forge cli
I would like to see the list in the developer console anyway, since there may be situations where I don’t have access to forge cli at some point but I would like to check on which my colleagues or myself in past worked and installed.
Glad that you are enjoying the developer console. Note that for now the avatar is only visible to you in the developer console, but in the near future, when we release the ability to distribute your app to administrators, they will be able to see the avatar when installing the app. Note that Forge apps are still not showing up in the UPM and cannot be published on Marketplace but it is possible for the avatar to be visible once that piece of work is completed.
Managing the distribution is coming next and it will be accessible through the developer console. We understand the importance of this feature for our developer community thus we are aiming to release it before we enable publishing and selling apps on Marketplace. Another change that is coming with the next release is that all Forge apps will be created as private by default and it will be up to the app owner to change the status to public so the app can be shared with administrators.
Note that currently granting management rights is not supported, however it is prioritised for Forge apps as evident on the Ecosystem roadmap, it is listed under app developer permissions. While granting management rights for 3LO apps in not currently on the roadmap your feedback will be considered during the next round of prioritisation work.
Do those near future plans include moving the Avatar declaration to the app itself, i.e. declare it in the manifest and add as an image resource? (While better than having none, I’d rather prefer not having manually maintain it in the developer console
@bjornbrynjar - Possibly a misunderstanding (partially due to my typo, partially to broken threading display here, and/or my questionable use of wink emoji):
I understand (and appreciate) that I can set an app Avatar in the developer console now, but I would prefer declaring (and maintaining) it in the Forge app manifest itself, i.e. keeping it in sync with my app development instead of this odd indirection via a separate web UI.
Thank you for your feedback, I will pass it to the relevant team! In the meantime, I will appreciate if you can share your thoughts on how you would expect team members to be able to manage your app later when we introduce multi-user app ownership? Would you expect all team members to be maintaining it through the CLI or there might be non technical team members who would use a web UI instead? Thank you in advance!
Coming from an app vendor perspective, I’d expect managing it through the CLI, usually not by team members directly, rather via CI/CD automation (i.e. I’d want our build/deploy pipelines to invoke the respective commands on behalf of a designated ‘company’ user).
I can see that this might not be the case for all aspects of app management, with e.g. adjusting the Avatar possibly being viewed as a non-technical aspect, especially for in-house or custom build apps. However, my focus is on automation and reliability - splitting central aspects of app distribution and deployment between the CLI (CI/CD) and manual Web UI interaction should be an absolute exception (or in the Avatar case, maybe a ‘manual’ override option, though I guess that would complicate things further).
Thank you for raising this issue to our attention. Note that this occurs intermittently and we are working on a fix as we speak. In the meantime it helps if you log out of www.developer.atlassian.com and log in again.
Thanks @AngelinaIgnatova - we’ve discovered a couple of other issues during our private distribution tests which only partially relate to the console as such, so for separation of concerns and to ease tracking for ecosystem partners, I’ve created resp. FRGE issues (and included the topic at hand while at it):