At the moment, in Github Actions, when a job has `uses:
actions/setup-go` it uses a specific commit from that repo.
In that commit, it used `set-output` somewhere, which is now deprecated
and will be disabled within the next month or so.
See here for more information:
https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/
This PR changes every instance where `actions/setup-go@...` was used and
replaces it with release `v2.1.3`. [From the release
notes](https://github.com/actions/setup-go/releases/tag/v2.1.3):
> Updated communication with runner to use environment files rather then
workflow commands
Which is what the above Github blog recommends doing.
---
Addationally, the latest version of this Github Action is
[`v4.0.0`](https://github.com/actions/setup-go/releases/tag/v4.0.0),
which you may want to update to in the future.
# Checklist for submitter
If some of the following don't apply, delete the relevant line.
- [x] Changes file added for user-visible changes in `changes/` or
`orbit/changes/`.
See [Changes
files](https://fleetdm.com/docs/contributing/committing-changes#changes-files)
for more information.
* Update go to 1.19.4
* Comment out failing package test
* Comment out ALL the packaging tests for windows for the moment
* Update go to 1.19.4
* Comment out failing package test
* Comment out ALL the packaging tests for windows for the moment
* Update changelog
* Bump versions
* Update changelog to reflect this being a security release
this modifies the migration order CI check to only check for added files
by:
1. Escaping the blob we give to git, so bash doesn't perform expansion,
this lets git handle the blob matching, which for reasons I don't
fully understand allows to find file renames.
2. Applying `--diff-filter=A`, which makes git only list file additions.
Related to #6142, this adds a CI check for the order of migrations.
As I noted in a comment on the workflow file, it's important to keep in mind that some migrations might still go unnoticed even with this check, example:
1. PR1 adds a migration, CI check pass
2. PR2 adds a migration, CI pass, gets merged
3. PR1 can still be merged because the CI checks aren't run again
The check will fail in `main` however, so if we find the current script to be reliable, we could setup a Slack ping or something similar, to make sure somebody takes a look
