@SeanBourke Thanks the for RFC and continued focus on Forging ahead.
Some questions though:
- What is the limit on Dynamic Remotes?
- If you configure a Dynamic Remote, do you also need to configure the Egress for that Remote? Either for the Frontend or the Backend?
By (automated) configuration of the egress it would be great if the popup that user are navigating away from Jira would no longer be shown. - If a user that is not a site-admin uses an app feature to configure a Dynamic Remote but doesn’t have himself the permissions to approve this, does a site-admin get a notification to approve the remote? Or will it simply fail?
In my use-case both site-admins and project-admins can configure new Jenkins sites to integrate with.
It would be doable if a project-admin can add the remote, but require a site-admin to approve it.
It would be a blocker in the project-admin would not be able to add the remote. - Can an app use Dynamic Remotes without making any manifest updates?
- Can a Remote that is already listed in the manifest add a new Dynamic Remote? (useful for migrations)
- Can a Remote access the configuration of a dynamic remote? (useful for migrations)
- What custom configuration can be stored with a dynamic remote? Can this include secret/secure configuration?
If the remote the customer is configuring is in full control of the customer, does that mean that Runs on Atlassian still apply to the app?
I fully understand that adding remotes, like the Github.com example, would not work with RoA, but a customer owned system on customer owned hardware/datacenter technically is not leaving the boundaries of the customer and I think would work with RoA.
Given the focus on Egress and Remotes, I understand if you want to move the RoA discussion to a separate RFC.
In my use-case I would be connecting Jenkins instances (possibly multiple) that the customer owns and operates to the app.
The app would need to access data from Jenkins, but also be able to connect to Jenkins to send data (like trigger a job, provide work item links for related items upon request from Jenkins).
All Egress actions can originate from both Jira and Jenkins in my case.
In case of Jira, it would be user defined, either by manual action or automation rules configured by the customer.
In case of Jenkins, it would be user defined, through interacting in Jenkins resulting in requesting Jira data related to the view within Jenkins.
Ideally traffic would be directed to the customer owned Jenkins instance directly, but I can see that during a migration path traffic would temporary go to a Marvelution owned system.