add-initial-element-template-link-check-file

[ztefanie]

Description

This PR adds the initial file, so my github action in connectors, does not need to handle file creation, but only modifying it. The update with all current links will soon be pushed, when I finished the new github action at connectors repo.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the DevEx team. (create draft PR and/or add hold label)
• This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• My changes are for an upcoming minor release and:
  • are in the /docs directory (version 8.8).
  • are in the /versioned_docs/version-8.7/ directory (version 8.7).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[pepopowitz]

These are all links to the /next version. A few questions:

1. Are they linking to /next intentionally?
2. If they aren't intentionally linking to /next, can they be changed to the current version?
3. If they're intentionally linking to /next (presumably because they don't exist in any version except next), could they link to a specific version number instead of /next? We don't currently have a rule to redirect /8.8 URLs to /next, but I think I would prefer adding one over preserving /next links via redirect rules.

Some background:

We don't usually worry about preserving redirects for /next docs, because we consider that area of the docs to be very fluid and undergoing change. To preserve these links would be an unusual thing for us to do, and I want to make sure they are the correct links before we commit to doing that.

[ztefanie]

Thanks for reviewing and this input. I am not super sure how to handle this.

To answer your questions:

1. Some are linking to next intentionally, but some are not.
2. We can change the latest versions of our element templates, but not really older ones, as they have be downloaded and are on different systems, e.g. on customers system where they have been downloaded to.
3. For the latest versions of the element templates I can adjust this and replace next with 8.8

So what we can do is:

A) Add a check to a github action in our/connectors repo, that no links with /next/ are in future element templates.
B) Fix links in the latest element templates to not link to next
Both (A+B) will require on your side that links to 8.8 are working, not like now, where they return 404. If i understand you correctly, that is what you suggested.
C) Older templates cannot be fixed and need either a redirect on your side, or if you do not want to this, will stay broken, but with A and B, this will "fade out" in the future, when customers update their element templates, but I would prefer them to be redirected and be working right away, but that's up to you.

[pepopowitz]

Sounds good, makes sense, and I agree on all points!

• I will let you know when I've got /8.8 links redirecting properly, so you can move forward on your end.
• I will add redirects for the few /next links that need them when I get the CI workflow properly checking these links, which I'll do on this PR.

[ztefanie]

I completed the tasks on our side in this PR (replacing next links in current element templates and adding a ci check for avoiding future linking to /next/). No links that linked to next where only available on 8.8 so i changed them to link to 8.7 or where possible to 8.6.