@bastirehm cool sounds good, I'll open an issue for the reference docs

@bastirehm @romaneisner if it's possible, can we give some information in the error message that would be actionable for the user? Something like:

Invalid agent configuration: .gitlab/duo/agent-config.yml does not match the required schema.. This itself is a little vague, so maybe we could add a link to the documentation as well?

Or is there somewhere we can show more details about the failure, maybe in the error log?

On a related note, I don't see anything like a specific reference page in the docs for the agent-config.yml (like we have for the .gitlab-ci.yml file). Is this something we need to consider adding?

@rsarangadharan yes I agree with your suggestion, framing this as a known issue would be the best way to format this 💯

Hey @bastirehm 👋 Could you please review this MR when you can? I noticed this when I was checking something else in this page and thought it might be contradicting our previous edit to make the human user the primary author in composite identity. Let me know if this isn't the case!

What does this MR do?

Compliance considerations for merge requests states that the MR is attributed to the service account and not the human user. This might be conflicting with the statement at the start of the page:

This composite identity ensures that any activities authored by the GitLab Duo Agent Platform are attributed to the human user.

This MR propose updating the MR section so it aligns with the above statement.

Related issues

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

Fiona Neill (cb2aeab5) at 16 Mar 11:32

@fsieverding hm, I've actually never merged past a danger failure so I'm not so confident about doing so. Would it be ok for you to do an interactive rebase? Sorry, I know they can be fiddly 🫣

Thanks @pishel65, that's a much more descriptive format. I'll defer to @rsarangadharan and @avonbertoldi as I'm only doing the maintainer review and this isn't one of my groups 🙏

Ideas

Examples

• Automate a repeating task (Flows)
• Act on an event in my project (Triggers)
• Run a multi-step investigation (Agents)
• Pick up where I left off (Sessions)

IA: Use case entry points

Either:

• Refactor DAP landing page with role based entry points (would require a wider IA refactor...)
• Or create use case landing page.

A role-based question, like "What's your role?" or "What kind of work do you do?"

• Use cards to create 3 or 4 entry points (need to look at JTBD). Something like:
  • Developer: writing, reviewing, debugging
  • Security engineer: triaging and solving vulnerabilities.
  • DevOps / platform engineer: pipelines, infrastructure, automation.
  • Engineering manager: planning, issue triage, visibility.

Closing as this was actually done in 18.9

!220001 (merged)

@sselhorn 👋 Your recent nav MR made me take another look at the org for the DAP pages. Just a small edit to reorganize them a bit so that Sesssions and Customization are closer to Flows and Agents. I'm also proposing moving Triggers under Flows. That feature came about before I joined agent foundations so let me know if that doesn't quite work.

Could you please review? 🙏 Thanks!

Fiona Neill (3df14862) at 16 Mar 10:20

Add navigation item to global navigation

• Moves Triggers under Flows. This helps make the association between triggers and flows more clear for users.

• Moves Code Suggestions further down the nav. This is so that Sessions and Customization are grouped next to Agents and Flows.

• Link to the merge request that introduced the new page: NA

• Give the MR a descriptive title.

• Optional. Link to the review app showing the new page:

Fiona Neill (a16af589) at 16 Mar 10:14

Hey @uchandran 👋 I was checking one or two things for code suggestions in my IDE and noticed this in the docs. Can you please review/merge? Thanks!

What does this MR do?

The navigation instructions for code suggestions in VS code were missing a level so adding that here.

Related issues

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.