We have four branches that test releasing a single platform:
release/release-test-only-dotnet-$platform
In these branches, only the given platform is enabled (these are also
.NET-only branches), with the idea that we're testing the build and publish of
a single platform. These branches have a 'release/' prefix, so that the go
through as much as possible of our release pipeline.
Hopefully by testing and making sure the following builds and publishes correctly:
* All platforms (the default for our build)
* Each platform by itself
Building and publishing more than one (but less than all four) platforms also
work.
This PR will automatically update these four branches from main every
Saturday, so that we'll be able to find and fix any problems that occur before
release date.
actions/github-script was recently updated from 3.1.0 to 6.3.1 (69de14c668), but unfortunately there were breaking changes:
* https://github.com/actions/github-script#breaking-changes
* https://github.com/actions/github-script/issues/242#issuecomment-1049167283
This would manifest as:
TypeError: Cannot read properties of undefined (reading 'listWorkflowRunArtifacts')
Error: Unhandled error: TypeError: Cannot read properties of undefined (reading 'listWorkflowRunArtifacts')
at eval (eval at callAsyncFunction (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13340:16), <anonymous>:3:38)
at callAsyncFunction (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13341:12)
at main (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13436:26)
at Module.858 (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13413:1)
at __webpack_require__ (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:24:31)
at startup (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:43:19)
at /home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:49:18
at Object.<anonymous> (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:52:10)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
So update our code to to use the new way to do things.
Bumps [actions/github-script](https://github.com/actions/github-script) from 3.1.0 to 6.3.1.
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
We have some problems when autoformatting PRs and the PR branch isn't fully
up-to-date with regards to the target branch.
I believe this is what happens:
1. When a PR is created (or modified), GitHub Actions will merge the PR branch
with the target branch, and parse/load the merged *.yml files.
2. Then when we run the autoformatter, we're working on the tip of the PR
branch (and not the merged result).
3. This means that we were using the list of projects to autoformat from the
merged branch, but exeuting on the PR branch. This resulted in spurious
autoformatting, because the autoformatted would autoformat more code than
expected.
The fix I'm implementing is to move the list of projects to autoformat to a
separate script in source code. That way we'll work upon the list of projects
as they show up in the PR branch, and not the merged results.
Also fix a merge conflict that made autoformatting not work, and make sure to not add any temporary files to the diff.
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Get the head repository using the correct syntax when trying to publish
autoformatted changes. This action is a 'workflow_run' action, and not a
'pull_request' action, and as such we must look in the 'workflow_run' object
for the data we need.
This will hopefully make the action able to publish results back to a fork.
It turns out that part of the logic has to exist in `main`, it won't
execute from a pull request.
This means it might take a while to get the logic right... so I made it
work in a personal repo first. This is the resulting code, hopefully it
works here too (but there's no way to know for sure before merging the
PR 😞
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 2 to 3.
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Implement a GitHub action to automatically format our source code.
This is implemented in two steps:
1. A restricted action is used to check if the code has any formatting issues, and if so, creates a patch to fix the code.
2. Another action is used to commit and push the patch (and add a comment to the PR notifying the submitter about the problems found).
This is because the first action will call 'dotnet format', which might be insecure in that it can execute code from the repository. This is not safe in a context that is allowed to push commits (because there are secrets in the environment) - so anyone could create a PR that would be executed as a part of 'dotnet format' and then look for our secrets and make them public. The restricted action's environment does not have any secrets, and it's thus safe to execute random code.
The second action will only execute if the corresponding file is in main, so this PR need to be merged before this can be fully implemented, and as such I've made the autoformatting opt-in (by adding the `actions-enable-autoformat` label). Once everything is confirmed to work properly, it will become opt-out instead.
Also, for now only a very simple project is autoformatted (xibuild.csproj), but the
idea is to fix source code incrementally, and add to the list of projects/code
we autoformat.
* Update FabricBot with more useful commands
* Remove the 'awaiting-customer-response' label and corresponding tasks
* Ignore people with admin permissions
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
* Update FabricBot with more useful commands
* Remove the 'awaiting-customer-response' label and corresponding tasks
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
This initial config file tells the author of an issue that if anybody adds the
`need-info` label, they have 7 days to answer before we close the issue due
to lack of response.