* Changed folder structure to allow multi group registration
* included actions.github.com directory for resources and controllers
* updated go module to actions/actions-runner-controller
* publish arc packages under actions-runner-controller
* Update charts/actions-runner-controller/docs/UPGRADING.md
Co-authored-by: Yusuke Kuoka <ykuoka@gmail.com>
* ci: prepare ci for multiple runners
* chore: rename dockerfiles
* chore: sup multiple os in makefile
* chore: changes to support multiple versions
* chore: remove test for TARGETPLATFORM
* chore: fixes and add individual targets
* ci: add latest tag back in
* ci: remove latest suffix tag
Co-authored-by: toast-gear <toast-gear@users.noreply.github.com>
* feat: clean and add docker-compose
* feat: make docker compose download arch aware
* fix: use new ARG name
* fix: correct case in url
* ci: add some debug output to workflow
* ci: add ARG for docker
* fix: various fixes
* chore: more alignment changes
* chore: use /usr/bin over /usr/local/bin
* chore: more logical order
* fix: add recursive flag
* chore: actions/runner stuff with actions/runner
* ci: bump checkout to latest
* fix: rootless build
Co-authored-by: toast-gear <toast-gear@users.noreply.github.com>
Co-authored-by: Yusuke Kuoka <ykuoka@gmail.com>
* ci: Fix runner builds but not pushes for forks
I noticed that our runners workflow is failing on docker-login due to that a pull request workflow job from a fork does not have access to repo secrets.
https://github.com/malachiobadeyi/actions-runner-controller/actions/runs/3390463793/jobs/5634638183
Can we try this, so that hopefully it suppresses docker-login for pull requests from forks?
* Update .github/workflows/runners.yaml
* fixup! Update .github/workflows/runners.yaml
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
* fixup! fixup! Update .github/workflows/runners.yaml
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
Signed-off-by: Yusuke Kuoka <ykuoka@gmail.com>
* Let it be a bug only when it's reproducible with official runner image
A custom runner image can break runners and ARC in interesting ways. Probably it's better to clearly state that ARC is not guaranteed to work with every custom runner image in the wild.
* Update .github/ISSUE_TEMPLATE/bug_report.yml
* Add workflow for validating runner scripts with shellcheck
I am about to revisit #1517, #1454, #1561, and #1560 as a part of our on-going effort to a major enhancement to the runner entrypoints being made in #1759.
This change is a counterpart of #1852. #1852 enables you to easily run shellcheck locally. This enables you to automatically run shellcheck on every pull request.
Currently, any shellcheck error does not result in failing the workflow job. Once we addressed all the shellcheck findings, we can flip the fail_on_error option to true and let jobs start failing on pull requests that introduce invalid or suspicious bash code.
Both fields can be useless when the reporter thought only one or two lines of the respective logs are relevant and it turned out we had to see another line later.
To avoid such a situation I'd like to change the field labels to include `Whole` so that it looks like `Whole Runner Pod Logs`, and ask to not omit the logs in the field description.
Honestly, I'm a bit tired of seeing issues filed with the default title "Bug" that are seemingly not related to real bugs!
I'm emptying it so that the reporter is more encourage to write up a sentence to describe the problem and they hopefully notice along the way that there are places to diagnose before considering it as a bug.
This introduces a linter to PRs to help with code reviews and code hygiene. I've also gone ahead and fixed (or ignored) the existing lints.
I've only setup the default linters right now. There are many more options that are documented at https://golangci-lint.run/.
The GitHub Action should add appropriate annotations to the lint job for the PR. Contributors can also lint locally using `make lint`.
I think we should at least recommend the reporter read the troubleshooting guide before submitting a bug report. It would give them more chances to realize it isn't a bug in some cases.
Even though we have a bug report form, we've seen so many issues being written in freestyle and I think every occurrence of it resulted in needing multiple hops for us to gather the information necessary for diagnosing the issue. I hope every bug report is more actionable. Now we disable blank issues so that the reporter is likely to choose the bug report form or Discussions depending on their situation.
Bassem Dghaidi
Tingluo Huang
Nikola Jokic
Callum Tait
Yusuke Kuoka
renovate[bot]
Cory Miller