Removing constraints on the CI- files, specifically the paths triggers.
Changes are hardly made in the Packages and scripts folders anymore as these files contain just basic configurations and shell files.
The new CI- files are such that whenever a PR or Push is made to the branch Main, the scripts should run.
The downside is that all PR's made to the Main branch will go through the testing process, even changes made in the README.md file.
The upside is that it gives an opportunity to be able to observe the CI-* files as they have not been running properly lately. Getting them to do their jobs is the focus of this PR.
With time, a follow up issue can be opened and PR submitted to add constraints for specific paths that should trigger the request for further optimization.
Screenshots
Using a local CI testing tool, I invoked a Pull request and it triggered the scripts correctly.
Checklist
- [x] My pull request has a descriptive title (not a vague title like `Update
index.md`).
- [x] My pull request targets the *default* branch of the repository (`main` or `master`).
- [x] My commit messages follow [best practices][best_practices].
- [x] My code follows the established code style of the repository.
- [ ] I added or updated tests for the changes I made (if applicable).
- [ ] I added or updated documentation (if applicable).
- [x] I tried running the project locally and verified that there are no
visible errors.
[best_practices]:https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53
## Developer Certificate of Origin
Developer Certificate of Origin
```
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
```
Fixes
Fixes #1000 by @MuluhGodson
Description
Removing constraints on the CI- files, specifically the paths triggers. Changes are hardly made in the
Packagesandscriptsfolders anymore as these files contain just basic configurations and shell files. The new CI- files are such that whenever a PR or Push is made to the branch Main, the scripts should run. The downside is that all PR's made to the Main branch will go through the testing process, even changes made in the README.md file.The upside is that it gives an opportunity to be able to observe the CI-* files as they have not been running properly lately. Getting them to do their jobs is the focus of this PR.
With time, a follow up issue can be opened and PR submitted to add constraints for specific paths that should trigger the request for further optimization.
Screenshots
Using a local CI testing tool, I invoked a Pull request and it triggered the scripts correctly.
Checklist
- [x] My pull request has a descriptive title (not a vague title like `Update index.md`). - [x] My pull request targets the *default* branch of the repository (`main` or `master`). - [x] My commit messages follow [best practices][best_practices]. - [x] My code follows the established code style of the repository. - [ ] I added or updated tests for the changes I made (if applicable). - [ ] I added or updated documentation (if applicable). - [x] I tried running the project locally and verified that there are no visible errors. [best_practices]:https://gist.github.com/robertpainsi/b632364184e70900af4ab688decf6f53 ## Developer Certificate of OriginDeveloper Certificate of Origin
``` Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. ```