v1 is coming to town

[derberg]

Reason/Context

There are many requests to the current workflow that I want to add first and then in v1 I want to introduce a major new feature that will provide per workflow configuration.

So you basically can specify that Workflow A will be copied over only to repos with Topic NodeJS and that Workflow B can be copied over to all the repos except for Topic Go.

I'm also considering the rename of the workflow (looking for good name 😄 ) and have it by default supporting not only workflows but basically any other file.

I start work in 2 weeks so looking forward for requirements

Description

Some discussion already started here https://github.com/asyncapi/.github/issues/130

@RostiMelk @Chris-Softrams @stockf @magicmatatjahu @KhudaDad414 Please share your opinions, requirements and especially a suggestion on the structure of the config file. I'm out next week so will definitely not start work yet, so it is a good time for you to share feedback

[stockf]

Thanks for continuing the development and asking for feedback. We talked about this and for us it would be good enough to specify a directory per topic and copy all the workflows in that directory. So for the config you would simply add directory: <path> . We would then simply have a 1-1 relation from directories/workflows to topics. Including other files would be great, especially for dependabot. I guess you would need to specify where the files go, though. And the third feature, we would really appreciate is, if the action would either reuse it's PRs or close them when a newer one is available.

[RostiMelk]

Gm! Great initiative. @stockf's suggestion sounds good to me. However, I am unfortunately no longer working at the agency where this workflow was setup, so I'll tag some of my previous colleagues to see if they have any thoughts. @dariuszksiazek @torbratsberg

[derberg]

@stockf thanks for kind words 🙇🏼

directory:

so you store your workflows inside directories in workflow directory and you want config to support that, that you config workflow/build/* should all go to repos of given topic?

And the third feature, we would really appreciate is, if the action would either reuse it's PRs or close them when a newer one is available.

I can't promise this one, I do not have a clear idea how would we accomplish it without some persistence. Basically, how do I know already existing PR should be closed as it consists of the same changes. Some of the API would let me do it, but that would not give me a 100% assurance I think. Why do you happen to have such cases? you do not have automerging in place?

[stockf]

so you store your workflows inside directories in workflow directory and you want config to support that, that you config workflow/build/* should all go to repos of given topic?

I'm not sure I completely understand. I suggest to have arbitrary directories in the "workflow distribution repository". E.g. workflows-a and workflows-b. In my global workflow action I can reference them like this:

jobs:
  replicate_changes:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - uses: derberg/global-workflows-support@v0.5.0
        with:
          topics_to_include: topic-a
          directory: workflows-a
      - uses: derberg/global-workflows-support@v0.5.0
        with:
          topics_to_include: topic-b
          directory: workflows-b

In the target repository it goes to .github/workflows.

When I think about it a bit more, maybe it's easier to have it structured as workflow-a/.github/workflow/... and just copy over to the root directory in the target repository. That would also make it very easy to add arbitrary files such as dependabot configurations

[derberg]

oh cool, I get it. So basically I need to enable anyone to specify what files or directories the action should clone, in what repositories (basing on topic) into what location.

# source repo: .github/workflows/builds`
# topic: `nodejs`
# target repo: `.github/workflows`

# source repo: `CONTRIBUTING.md`
# topic: `library`
# target repo: `.github/CONTRIBUTING.md`

# source repo: `.github/FUNDING.yml`
# topic: `library`
# target repo: if no config is provided, we just copy it into the same location as source repo which is `.github/FUNDING.yml`

btw I have never thought someone would use this workflow like 👇🏼

jobs:
  replicate_changes:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v2
      - uses: derberg/global-workflows-support@v0.5.0
        with:
          topics_to_include: topic-a
          directory: workflows-a
      - uses: derberg/global-workflows-support@v0.5.0
        with:
          topics_to_include: topic-b
          directory: workflows-b

kinda obvious, but never considered it. I'll make sure this flow is also supported if someone doesn't want to store a separate config file for the workflow.

[stockf]

I can't promise this one, I do not have a clear idea how would we accomplish it without some persistence. Basically, how do I know already existing PR should be closed as it consists of the same changes. Some of the API would let me do it, but that would not give me a 100% assurance I think. Why do you happen to have such cases? you do not have automerging in place?

Use case: It sometimes happens that I update the global workflows and distribute them, then find a mistake or make another improvement and distribute again. Then I have two PRs in each of the repositories. I see the problem with finding the correct PRs. My take on that would be to use a static prefix and the commit-id of the latest commit from my "global-workflow repository" as the branch name. Then I could look for open PRs based on that naming and the author.

[derberg]

My take on that would be to use a static prefix and the commit-id of the latest commit from my "global-workflow repository" as the branch name. Then I could look for open PRs based on that naming and the author.

the thing is that this action also supports manual triggering with workflow_dispatch event. In this case, there is no commitID. So then branch consists of random math number. Sorry but I will not work on this feature for 1.0. My strong recommendation is you have a autoapprove and automerge workflows in place that merge your changes immediately. So you do not have 2 PR, you just make 2 changes.

Btw, over last few weeks I added some features to the project, before 1.0. Wanted to remind myself with codebase first and do some refactor

[stockf]

I just tested out the new workflow. It's a big improvement that I'm not tied to the .github/workflows directory anymore. Unfortunately there is still an issue with subdirectories. I filed a bug report for that.