Do not restrict workflow triggers to addon path

[CyrilleB79]

Issue

In #21, a restriction has been added to workflow triggers so that the workflow runs only if files in the addon subfolder are modified.

Though as discussed in #21 (comment), modifying files outside the addon folder may have an impact on the generated .addon file:

• some files are copied in the bundle (readme.md, style.css)
• some files control its content, e.g. buildVars.py controls the bundled manifest file, sconstruct modification can have any effect, including on what is in the bundle, etc.

Solution

Removed the path restriction.

Note

Alternative solution was discussed, e.g. exclude some folders from the trigger rather than including only the "addon" folder. Though, it seems to me that making any hypothesis on which file / folder impacts the add-on bundle's content is quite fragile.

[seanbudd]

Happy to merge this, I think it would be nice to have a solution that avoids checks failing on PRs like this though.

[CyrilleB79]

OK.

@nvdaes, the goal of the work in #21 was not very clear to me. Is there an add-on example of yours using the same workflow (or similar) to the one that you have pushed in #21?

Seems to me that, at least that the following is not correct:
uv pip install

The target is missing. Maybe just a dot?

Additionally, is there some sens to run the build.yml in this template repo? It's made for add-ons, not for the template...
Maybe we could add the following condition to the first job (build), the second job being skipped due to the dependency on the first job:
if: github.repository != 'nvaccess/addonTemplate'
Alternatively, if we want thing clearer (e.g. in case a third job is added in the future), we may also add the condition to both jobs (build and upload_release)

[nvdaes]

@CyrilleB79 , I think that your thoughts are right.
Seems that using uv pip install is not right. In the crowdinRegistration repo, created mostly for learning and testing since we will want to use nvdaL10n repo, we have this code, which worked whenit was used:

      - name: "Set up Python"
        uses: actions/setup-python@v6
        with:
          python-version-file: ".python-version"
      - name: Install the latest version of uv
        uses: astral-sh/setup-uv@v6

I searched a lot of documentation for that work, as much as possible. Of course, now the version of actions may be updated.

About addonTemplate, I agree with you. We can restrict this if repo is nvaccess/addonTemplate