search

dotnet / runtimelab

This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
MIT License
1.36k stars 188 forks source link

Change the trigger for the runtime/main -> runtimelab/runtime-main #2617

Closed pavelsavara closed 1 week ago

pavelsavara commented 2 weeks ago

try to trigger the flow from changes of internal/dotnet-runtime main branch instead of maestro

mmitche commented 1 week ago

@jkotas Who is responsible for runtimelab these days?

jkotas commented 1 week ago

@jkotas Who is responsible for runtimelab these days?

If you are looking for who is responsible for fixing problems with runtimelab, it is generally the people who work on or sponsor currently active experimental project in dotnet/runtimelab. It includes myself, @pavelsavara, @kotlarmilos.

I think it would be fine to delete this synchronization job. It does not have a lot of value. If somebody wants to do merge from dotnet/runtime:main (it does not happen very often), it is only a few git commands to fetch the remote.

If you want to keep it, I think it should be triggered from public github only.

pavelsavara commented 1 week ago

I think it would be fine to delete this synchronization job.

I like that idea. That looks like nice way out of maintaining security token BotAccount-dotnet-maestro-bot-PAT used in https://dev.azure.com/dnceng/internal/_build?definitionId=906&_a=summary

There are other places where it's used.

If you want to keep it, I think it should be triggered from public github only.

We have another code flow which does "fast forward" from github runtime/main to azdo dotnet-runtime/main. So I thought that triggering it of off azdo would be easier.

As far as I can understand, triggering azdo directly from (another) github repo requires "service connection" and webhook on github side. See docs

I prefer not to do it this way.