Update directly executed scripts inside workflows

[thepetk]

What does this PR do?

It ensures that all script executions, inside .github/workflows are not directly executed and that the script file is passed to the appropriate shell defined by the scripts shebang. For example. in the case of a bash script ./build.sh would become bash ./build.sh.

Which issue(s) does this PR fix

fixes #973

PR acceptance criteria

Testing and documentation do not need to be complete in order for this PR to be approved. We just need to ensure tracking issues are opened.

• Open new test/doc issues under the devfile/api repo
• Check each criteria if:
• There is a separate tracking issue. Add the issue link under the criteria
  or
• test/doc updates are made as part of this PR
• If unchecked, explain why it's not needed

• Unit/Functional tests

• QE Integration test

• Documentation

• Client Impact

How to test changes / Special notes to the reviewer

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (a6c32fc) 35.79% compared to head (1d99754) 35.79%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1107   +/-   ##
=======================================
  Coverage   35.79%   35.79%           
=======================================
  Files          52       52           
  Lines        6679     6679           
=======================================
  Hits         2391     2391           
  Misses       4144     4144           
  Partials      144      144           

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[michael-valdron]

Your changes looks good, just found these two lines missed:

• https://github.com/thepetk/devfile-api/blob/cd2ef8a99f2176a998422e2a1a1e8e6ff114aef3/make-release.sh#L84
• https://github.com/thepetk/devfile-api/blob/cd2ef8a99f2176a998422e2a1a1e8e6ff114aef3/build/typescript-model/generate.sh#L33

[amisevsk]

IMO file permissions are a part of the repo and should be maintained in PRs (this allows e.g. someone committing a non-executable ./docker-run.sh, which isn't ideal) but I won't block merge.

[thepetk]

Your changes looks good, just found these two lines missed:

• https://github.com/thepetk/devfile-api/blob/cd2ef8a99f2176a998422e2a1a1e8e6ff114aef3/make-release.sh#L84
• https://github.com/thepetk/devfile-api/blob/cd2ef8a99f2176a998422e2a1a1e8e6ff114aef3/build/typescript-model/generate.sh#L33

@michael-valdron maybe my bad I've checked only the .github/workflows/ dir. I'll go through once more.

[michael-valdron]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: michael-valdron, thepetk

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[michael-valdron]

IMO file permissions are a part of the repo and should be maintained in PRs (this allows e.g. someone committing a non-executable ./docker-run.sh, which isn't ideal) but I won't block merge.

@amisevsk I agree that we should be maintaining our UNIX permissions. There is however an issue with the reliability of the Windows filesystem and results in core.filemode setting for git being set to false. This sometimes results in the removal of the UNIX execution permission during commits in Windows. Another discussion about this be found here: https://stackoverflow.com/questions/68281828/how-can-i-keep-the-execution-permissions-when-cloning-a-repository-in-windows

The changes here are to allow required scripts for the CI to execute without having the UNIX execution permission set so that PRs from Windows contributors no longer have unintended permissions changes. This comes with an additional good and bad side, the good is that the permissions are being reduced so there is no security concerns here, the bad is that UNIX-based users will have a slight inconvenience of executing these scripts like build.sh using bash ./build.sh instead of ./build.sh.

In addition to the current changes, we are planning to:

1. Update any permissions that are 755 to 644 and maintain these permissions in all PRs
2. Update the documentation to instruct how these script should be run with the bash command
   • Additionally, any existing instructions will be updated to reflect this