Customer Reference Implementation
@gweaver would like to setup a reference implementation project at https://gitlab.com/tech-marketing/demos/gitlab-agile-demo/awesome-co to help customers understand how to use gitlab-triage
for common automation situations on GitLab efficiently.
Feedback on customer calls has been that https://gitlab.com/gitlab-org/quality/triage-ops/ is a bit overwhelming for non-experienced Ruby developers.
Questions
- What automations do customers most commonly request for namespaces?
- How can we structure the documentation to annotate what the policies and pipeline schedules are doing to target the policies over the right group/project to reduce duplication?
Slack discussion:
https://gitlab.slack.com/archives/C3JJET4Q6/p1622565705161700
I’m working on a webinar and want to highlight gitlab-triage . As I’m working on setting up the demo, what’s the best way to create a single set of policies that can will apply to all projects/groups within a namespace?
more or less create some policies in Ops (https://gitlab.com/tech-marketing/demos/gitlab-agile-demo/awesome-co) that will run scheduled triage policies across Awesome Co and all children subgroups/projects. There is more and more demand for “automation” within GitLab so I’m trying to show how to easily setup and use triage so we have some sort of stop-gap until we build it properly into the product.
it just seems like there ought to be a better way than duplicating policies in all of the projects within the subgroups when the goal is to all have them follow the same set of policies / rules
What type of automation would you be looking to run? I don’t think you’d need to duplicate policies but happy to pair with you on it. Policies can target groups but they have to do the same thing. Apologies for the slow delay my son is home today and I keep getting interrupted :kids:
Can we do some synchronous time on this next week? I’m happy to build out a POC with you on this. (edited)
I’m out next week but let’s find some time the following week. I need to better understand how to apply it for use cases around planning, product management, and basic workflows. I’m working on a webinar but i’d also like to work on improving the documentation and adding more use cases / recipes so our customers have an easier time onboarding.
it comes up on almost every customer call I have so the demand is definitely building
Duplicating the policies should not be needed, if the same actions are being done in subgroups or projects then the policies should be written once and run multiple times at the different levels. GitLab’s Milestone Reschedule policy is a complex example that I’ve tried to use for customers. On x date we try to move issues forward that fit a criteria for our process, we defined that logic in a policy and run it with the linked automation on a schedule. Let’s work together to define a reference customer implementation. I’ve been on 2-3 customer calls for gitlab-triage and agree that we need something to clearly show customers how to use it better than what we can in triage-ops for non-Ruby developers.
/cc @acroitor