Added external feed trigger docs

[MissedTheMark]

To save you running the project locally, this is a rendered version of the new triggers page as at commit d13b9c2:

Changes to the Releases and Dependencies page

Before

After

Changes to the ARC page

Added this heading to the ARC page (now Built-in package repository triggers):

There are a few other changes included in the move from ARC to built in package repo triggers.

[sc-61201]
[sc-73064]

[eddymoulton]

Perhaps changing to an image with an automatically deployed phase would be good here?

[shortcut-integration]

This pull request has been linked to:

• Shortcut Story #61201: Creating documentation
• Shortcut Story #73064: Update ARC etc docs

[steve-fenton-octopus]

@MissedTheMark I have a PR to resolve your spelling woes here:

#2237

[nikita-dergilev]

Should we highlight in the doc intro that this feature is for Kubernetes? Maybe the first sentence could say something like, 'This feature enables pull-driven deployments for Kubernetes steps'.

Should we have a history section in the doc?

Should we explain how the feature works? Something like it creates a task every 3 minutes, etc.

I believe the channel and source sections miss whys. I.e. what are the use cases for this? We can explain that you might want to test an interim version and don't want to promote it to production, in this case you can use this tag, or if it's a hothix, use this. The same is true for the source selection; we could say something like, 'If you have a 3rd party repo, you can monitor all the included packages to spot updates automatically).

The paragraph above makes me think that we'll benefit from a new doc, something like 'triggers best practices' or 'triggers use cases'. We could show a few examples like

• 3rd party Helm chart where customers don't even use variables in the chart but just specify containers to monitor
• Microservices (multiple containers), where we monitor just the last container to avoid premature releases
• Security updates where we immediately push to production all the containers with security tags (maybe, it's a silly example).

[eddymoulton]

@nikita-dergilev

Should we highlight in the doc intro that this feature is for Kubernetes? Maybe the first sentence could say something like, 'This feature enables pull-driven deployments for Kubernetes steps'.

Should we have a history section in the doc?

Should we explain how the feature works? Something like it creates a task every 3 minutes, etc.

These are good points, I'll make some updates

The second half of the message I've referenced in this card.

Unsure if we'll do it as a separate PR or bring it in here too.
I think the plan will be to merge these docs as we roll out to prod.