Official -> "The individual jobs in a workflow can interact with (and compromise) other jobs. For example, a job querying the environment variables used by a later job, writing files to a shared directory that a later job processes, or even more directly by interacting with the Docker socket and inspecting other running containers and executing commands in them.
This means that a compromise of a single action within a workflow can be very significant, as that compromised action would have access to all secrets configured on your repository, and can use the GITHUB_TOKEN to write to the repository. Consequently, there is significant risk in sourcing actions from third-party repositories on GitHub. "
https://docs.github.com/en/actions/learn-github-actions/security-hardening-for-github-actions#using-third-party-actions
With this change, the test code will not be built unless `rake test` is
run, so there will be almost no side effects even if `enable_test` is
always set (but, gems specified by `add_test_dependency` are included
in `libmruby.a`).
Also added are `test: build` task, which only builds the test code
(including the main code), and `test: run` task, which only runs tests
independent of build. Therefore, the idiom for building in parallel and
not running tests in parallel is `rake -m test:build && rake test:run`.
* Skip if commit message contains `ci skip`, `skip ci`, or `skip gha`
ENCLOSED WITH BRACKETS (excluding lint job).
* Separate build and test. This is because builds can be run in parallel,
but running tests in parallel can cause logs to get mixed up or not
finished.
* Don't use Chocolatey because it seems to take 1-2 minutes to start up.
* Use the cache better.
* Use `actions/checkout@v2` instead of `actions/checkout@v1`.
* Remove unnecessary package installation.
* Remove unnecessary flag settings.
* Remove `-j` for rake because it doesn't seem to have any effect.
* Rename `main.yml` to `oss-fuzz.yml` to clarify.
Run on pull request only
Using https://www.npmjs.com/package/markdownlint-cli
Lint Markdown for rules:
- MD009/no-trailing-spaces
- MD012/no-multiple-blanks
- MD022/blanks-around-headings
- MD031/blanks-around-fences
- MD032/blanks-around-lists
Currently, there are build configuration files for CI, `travis.rb` and
`appveyor.rb`, but they are used for GCC/Clang and MSVC, not for Travis CI
and Appveyor, respectively.
Therefore, rename them to `gcc-clang.rb` and `msvc.rb`, respectively, and
move them under `build_config/ci/` to clarify that they are for CI.
I tried `$GITHUB_PATH` and `$GITHUB_ENV` instead of `set-env`, but
for some reason path was not recognized, so I changed to using
`ACTIONS_ALLOW_UNSECURE_COMMANDS`.
* In explanation of mruby, the expression `build_config.rb` is frequently
used including official documents, so I think that it will not make sense
if the file is no longer used.
* The `MRUBY_TARGET` mechanism seems to have little improvement, so I don't
think it should be changed to avoid unnecessary confusion.
* `MRUBY_TARGET` and `MRuby.targets` represent somewhat different things,
so using the same term "target" is a bit confusing.
The mechanism that can be written short when using a file under
`build_config` (renamed from `target`) directory remains
(`build_config/${MRUBY_CONFIG}.rb` is used if the path specified
in `MRUBY_CONFIG` doesn't exist).
John Bampton