Add include options

[Tjitse-E]

Reason/Context

Currently there are these settings two settings available:

files_to_ignore: name_of_file_where_this_action_is_used.yml
repos_to_ignore: repo1,repo2

For bigger organisations that have a lot of different repositories it would be easier to also have the optional settings:

files_to_include: name_of_file_where_this_action_is_used.yml
repos_to_include: repo1,repo2

This will allow the organisation to have workflow X copied only to specific repo's, because these repo's are of the same style or language. It would be a lot of work to maintain the repos_to_ignore option, the 'include' option solves this.

[derberg]

@Tjitse-E hey, sorry for late response.

• files_to_include would still support files only from workloads dir?
• repos_to_include definitely makes sense. To be honest, recently I was thinking that the exclude/include is anyway kinda manual, and always requires a commit to change. I was thinking maybe using github tags would be better? So you specify in the workflow just once what is the tag name that is included/supported, and then just tag a repo to get it supported by the workflow. Thoughts?

[Tjitse-E]

Hi @derberg

Using tags seems like a great idea! So something like tags_to_include as an alternative to repos_to_ignore seems like a lot less manual work.

files_to_include would still support files only from workloads dir?

Yes, files_to_include would be the opposite of files_to_ignore

[derberg]

ah, I somehow have issue with ignore vs include, I mean when I see include I would expect exclude and not ignore. Seems like a trivial problem but bothers my head 😄

also, do you think that options for ignore and include should be mutually exclusive? or should there be just a priority, like ignore has higher power over include. So if file is on ignored list, and then on include list, we should ignore it anyway, with a proper log message. Thoughts?

[Tjitse-E]

So if file is on ignored list, and then on include list, we should ignore it anyway, with a proper log message. Thoughts?

In my opinion, letting the user know that something is ignored and logging it seems good enough. A priority system seems unnecessary/to complex.

[derberg]

@Tjitse-E 👍🏼

was it something you wanted to contribute? or rather expect is supported?

[Tjitse-E]

@derberg it seems like a good enhancement for this workflow. I'm not planning on contributing in the short time unfortunally (not enough time, like most dev's....), but maybe in the future.

[derberg]

is it something you would use? then you know, it is more motivating to work on it 😄

[Tjitse-E]

@derberg yeah this enhancement would make it very usefull for me, so then I would definitely use it.

[Tjitse-E]

@derberg I did some work on the GrapQL part today so the user has more control of the repositories fetched: https://github.com/Tjitse-E/global-workflows-support/blob/add-graphql-filters/lib/api-calls.js#L15-L39. I can now search only for repos that are not archived, private and have topic X.

This approach also solves https://github.com/derberg/global-workflows-support/issues/9 for me, because I can exclude the really old archived repo's.

[derberg]

awesome, can you show yaml file, the workflow file, how it looks there

[Tjitse-E]

name: Copy global workflows

on:
    push:
        branches: [ "master" ]

jobs:
    replicate_changes:
        runs-on: ubuntu-latest
        steps:
            -   uses: actions/checkout@v2

            -   uses: Tjitse-E/global-workflows-support@test-fix-git
                with:
                    github_token: ${{ secrets.PERSONAL_ACCESS_TOKEN_GITHUB }}
                    files_to_ignore: global_workflow_copy.yml
                    repo_visibility: private
                    repos_archived: false
                    repo_topic: "global-workflow"
                    committer_username: "Tjitse-E"
                    committer_email: "abc@efg.nl"
                    commit_message: "CI: Update global workflows"

In my fork the new options are required, but these should be optional ofcourse. I'm using this as we speak for my organisation :rocket:

[derberg]

can you open a PR so it is easier to have a look and comment? of course if you are interested in pushing it main action 😄

[derberg]

@Tjitse-E I'm closing this issue as thanks to @RostiMelk we now have support for ignoring archived and private repos + narrowing down the list of repos using topics -> https://github.com/derberg/global-workflows-support/releases/tag/v0.5.0