Genesis repipe doesn't add ci.yml to the observed paths

[patryk-kozak]

When generating a new pipeline based on PIPELINES.md (https://github.com/genesis-community/genesis/blob/main/docs/PIPELINES.md) it doesn't add ci.yml or the file that actually contains the pipeline: definition to the paths for [env]-changes.

It would be best if during the run of genesis repipe it checks what is the name of the file and uses it.

Current: modifying CI itself does not trigger [env]-changes
Expected: modifying CI triggers it and runs to validate it

Drawback: it may be unwanted for some users that the pipeline is run when it definition changes in observed git resource.
Possible scenarios:

• users use only one branch for all changes, want to modify pipeline and push it to a single branch to share changes (a: use branches for work-in-progress)

Default resource:

resources:
\- icon: github
  name: [env]-changes
  source:
    branch: [branch]
    paths:
    - .genesis/bin/genesis
    - .genesis/kits
    - .genesis/config
    - ops/*
+   - ci.yml
    - kit-overrides.yml
    -[env].yml

Right now users can create the override of resource to append to existing one the file:

resources:
- name: dev-changes
  source:
    paths:
    - ((append))
    - ci.yml

[dennisjbell]

Modifying ci.yml doesn't impact the pipeline at all, nor does it need to propagate through the pipeline. ci.yml is the definition for the entire pipeline, and as such, operates outside the pipeline. To have its changes take effect, you must use the genesis repipe command. The detection of a change to ci.yml does not mean the pipeline has been updated.

I can see a use case for a separate pipeline to track the detection of changes to ci.yml, and trigger a repipe, but that is out of scope of the pipeline itself (we've found its generally a bad practice for a pipeline to repipe itself)