[{"_1":2,"_177":-5,"_178":-5},"loaderData",{"_3":4,"_13":14,"_21":22,"_156":157},"root",{"_5":-5,"_6":-7,"_7":8,"_9":-7,"_10":11,"_12":-7},"currentUser","primaryEmail","siteVerification","6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI","toast","enableDev",false,"incidentStatus","routes/_layout",{"_15":-5,"_16":17,"_18":17,"_19":11,"_20":11},"username","isAskGordonEnabled",true,"isUsingNewTemplate","showMinimalLanding","showHoneypotTrap","routes/_layout.r.$namespace.$reponame",{"_23":24,"_25":-5,"_26":11,"_27":11,"_28":29,"_30":31,"_32":-5,"_33":11,"_34":35,"_85":86,"_109":110,"_147":-5,"_148":11,"_149":17,"_150":11,"_151":-5,"_152":11,"_153":-5,"_154":155},"canonicalUrl","https://hub.docker.com/r/borsng/mysqlnd/tags","mcpServer","canSeeDockerfile","canSeeAutobuilds","namespace","borsng","reponame","mysqlnd","cloudBuildSource","isAutobuildsAvailable","repo",{"_36":37,"_38":39,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":51,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":69,"_70":71,"_76":11,"_77":78,"_82":29,"_83":84},"categories",[],"content_types",[40],"image","date_registered","2021-02-25T21:59:11.282051Z","description","MySQL 8 with the old authentication system","is_private","last_updated","2021-07-26T18:05:00.133764Z","last_modified","2024-10-16T13:48:34.145251Z","media_types",[52],"application/vnd.docker.container.image.v1+json","name","pull_count",61798,"repository_type","star_count",0,"status",1,"status_description","active","source","collaborator_count","full_description","A merge bot for GitHub pull requests\n====================================\n\n[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#https://github.com/bors-ng/bors-ng)\n\n[![Bors enabled](https://bors.tech/images/badge_small.svg)](https://app.bors.tech/repositories/3)\n\n[Bors-NG] implements a continuous-testing workflow where the main branch never breaks.\nIt integrates GitHub pull requests with a tool like [Travis CI] that runs your tests.\n\nOther resources:\n\n* [Home page](https://bors.tech/)\n* [Documentation](https://bors.tech/documentation/)\n* [Support forum](https://forum.bors.tech/)\n* [Publicly hosted instance (public repositories only)](https://app.bors.tech/)\n\n\n# But don't GitHub's Protected Branches already do this?\n\nMost CI systems, like Travis, Jenkins, and GitHub Actions both run the test suite\non every branch after it's pushed to and every pull request when it's opened, and\nGitHub can block the pull requests if the tests fail on them. To understand why\nthis is insufficient to get an evergreen main branch, imagine this:\n\n * #### Pull Request \\#1: Rename `bifurcate()` to `bifurcateCrab()`\n\n Change the name of this function, as well as every call site that currently\n exists in the main branch. I've thought of making it a method on Crab instead\n of on Sword, but then it would be `bifurcateWithSword()`, which hardly seems\n like an improvement.\n\n * #### Pull Request \\#2: `bifurcate()` after landing, in addition to before\n\n Adds another call to `bifurcate()`, to make sure it gets done even if we\n skip the pre-landing procedure.\n\nWhen both of these pull requests are sitting open in the backlog, they will\nboth be tested with the main branch. Assuming they both pass, GitHub will happily\npresent the Big Green Merge Button. Once they both get merged, the main branch\nwill go red (Method `bifurcate()` not found).\n\nIn addition to the testing requirements, GitHub can also be set to block pull\nrequests that are not \"up to date\" with the main branch, meaning that problems\nlike this can show up. This fixes the problem, by requiring that the main branch\nonly contain a snapshot of the code that has passed the tests, but it requires\nmaintainers to manually:\n\n 1. \"Update the pull requests,\" merging them onto main without changing\n main itself\n 2. Wait for the test suite to finish\n 3. Merge the pull request when it's done, which is a trivial operation that\n can't break the test suite thanks to step 1\n\nAnd it has to be done for every pull request one at a time.\n\nThis is similar to, but less efficient than, the process that bors automates.\nInstead of merging, you add reviewed pull requests to a \"merge queue\" of pull\nrequests that are tested against the main branch by copying it to a staging branch\nand merging into that. When the status of staging is determined (either pass or fail),\nbors reports the result back as a comment and merges staging into main if it was a pass.\nThen it goes on to the next one.\nBased on the assumption that the tests usually pass once they're r+-ed,\nbors actually tests them in batches (and bisects if a batch fails).\n\nNote that bors is not a replacement for your CI system. It just implements\nthis workflow.\n\n\n# How it works\n\nBors is a [GitHub Application], so (assuming you already have GitHub Actions set up), getting bors set up requires three steps:\n\n 1. Add the app to your repo in GitHub. [Click here to use the publicly hosted instance.](https://github.com/apps/bors/installations/new)\n 2. Commit a bors.toml with these contents:\n\n status = [\"ci\"]\n \n 3. Set up a workflow step with the same name. For example:\n\n ci-success:\n name: ci\n if: ${{ success() }}\n needs:\n - exfmt\n - test\n runs-on: ubuntu-latest\n steps:\n - name: CI succeeded\n run: exit 0\n\nTo use it, you need to stop clicking the big green merge button, and instead leave a comment with this in it on any pull request that looks good to you:\n\n bors r+\n\nAs commits are reviewed, bors lumps them into a queue of batches. If everything passes, there will just be two batches; the one that's running, and the one that's waiting to be run (and is accumulating more and more pull requests until it gets a chance to run).\n\nTo run a batch, bors creates a merge commit, merging the main branch with all the pull requests that make up the batch. Instead of pushing the merge commit immediately, however, it will instead push it to the `staging` branch. They'll look like this:\n\n Merge #5 #7 #8\n\n 5: Rename `bifurcate()` to `bifurcateCrab()`\n 7: Call `bifurcate()` in the `onland` event handler\n 8: Fix crash in `drive()`\n\nIf the build passes, the main branch gets fast-forwarded to meet the staging branch. Since the main branch contains the exact contents that were just tested, bit-for-bit, it's not broken. (at least, not in any way that the automated tests are able to detect)\n\nIf the build fails, bors will follow a strategy called \"bisecting\". Namely, it splits the batch into two batches, and pushes those to the queue. In this example, the first batch will look like this:\n\n Merge #5 #7\n\n 5: Rename `bifurcate()` to `bifurcateCrab()`\n 7: Call `bifurcate()` in the `onland` event handler\n\nThis batch will still fail, because the second patch inserts a call to a function that the first patch removes. It will get bisected again, as a result.\n\nThe second will still pass, though.\n\n Merge #8\n\n 8: Fix crash in `drive()`\n\nThis one will work, causing it to land in the main branch, leaving the first two still in the backlog.\n\n Merge #5\n\n 5: Rename `bifurcate()` to `bifurcateCrab()`\n\nThis one will pass, since the PR it conflicts with (#7) is sitting behind it in the queue.\n\n Merge #7\n\n 7: Call `bifurcate()` in the `onland` event handler\n\nWhen a batch cannot be bisected (because it only contains one PR), it gets kicked back to the creator so they can fix it.\n\nNote that you can watch this process running on the [dashboard page] if you want.\n\nAs a convenience, you can also run `bors try`, which will kick off a build the same way `r+` would, but without actually pushing it to the main branch even if it does succeed. To help keep them separate, `r+` merge commits go in `staging` and `try` builds go in `trying`.\n\n[Bors-NG]: https://bors.tech/\n[GitHub Application]: https://github.com/settings/installations\n[Travis CI]: https://travis-ci.org/\n[dashboard page]: https://app.bors.tech/\n\nThe [original bors] used a more simple system (it just tested one PR at a time all the time).\nThe one-at-a-time strategy is O(N), where N is the total number of pull requests.\nThe batching strategy is O(E log N), where N is again the total number of pull requests and E is the number of pull requests that fail.\n\n[original bors]: https://bors-ng.github.io/guide/2017/04/26/whirlwind/\n\n# How to run it on your local machine\n\nIf you're using a macOS or Linux command line with Docker on it,\n`./script/setup && ./script/server` will set up a local instance,\nwith a mocked-out GitHub instance, using Docker to pull in all the underlying dependencies.\nThe web server ends up running on .\nYou can get an Elixir REPL running in the same context as the webserver by running\n`repl` instead of `server`. To run the tests, run `test` instead of `server`.\n\nIf you log in, it will log you in with the user \"space.\"\nThere won't be any repositories, and space will not have admin perms.\nYou can use the [User model] to give space admin rights,\nand the [WebhookController] and [GitHub ServerMock] to create the repo.\n\n[User model]: https://bors-ng.github.io/devdocs/bors-ng/BorsNG.Database.User.html\n[WebhookController]: https://bors-ng.github.io/devdocs/bors-ng/BorsNG.WebhookController.html\n[GitHub ServerMock]: https://bors-ng.github.io/devdocs/bors-ng/BorsNG.GitHub.ServerMock.html\n\n## Setting it up without Docker, like on Windows home edition\n\nThe main things you'll need to run Bors on your laptop are:\n\n * Familiarity with the command line\n * Elixir, with a full installation of OTP (the `esl-erlang` package is sufficient)\n * PostgreSQL; the configuration for it is in config/dev.exs\n * Stock C compilation tools, because some of bors's dependencies use NIFs\n * A git client, which you probably already have for downloading this repository\n * NodeJS, to perform asset compilation\n\nI use [Portable PostgreSQL],\nthe [Chocolatey] packages for Elixir, Git, and NodeJS,\nand the Visual C++ build tools from Microsoft.\n\n[Portable PostgreSQL]: https://sourceforge.net/projects/postgresqlportable/\n[Chocolatey]: https://chocolatey.org/packages/Elixir\n\nYou can then run it using `mix`:\n\n $ mix ecto.create\n $ mix ecto.migrate\n $ mix phx.server\n\nAnd it'll run with the GitHub API mocked-out.\n\nTo run tests, run:\n\n $ mix test\n $ mix dogma\n $ mix dialyzer\n\n# How to set up your own real instance\n\n## Step 1: Register a new GitHub App\n\nThe first step is to [register a new Github App] on the GitHub web site.\n\n[Register a new GitHub App]: https://github.com/settings/apps\n\n### App settings\n\nThe *Github App name*, *description*, and *homepage URL* are irrelevant, though I suggest pointing the homepage at the dashboard page.\n\nThe *user authorization callback URL* should be at `/auth/github/callback`.\n\nLeave the *setup URL* blank.\n\nThe *webhook URL* should be at `/webhook/github`.\n\nThe *webhook secret* should be a randomly generated string. The `mix phx.gen.secret` command will work awesomely for this. Keep this handy to specify the same value in the bors configuration (you can also edit this value later if you need to).\n\n### Required GitHub App permissions\n\n#### Permission summary\n\nFor each of these sections, set the following overall section permissions and check the following webhook event checkboxes. Explanations for why bors-ng needs each of these permissions are below.\n\n- *Repository metadata*: Read-only (no choice)\n - *Repository* (Repository created, deleted, publicized, or privatized)\n- *Repository administration*: No access\n- *Commit statuses*: Read & write\n - *Status* (Commit status updated from the API)\n- *Deployments*: No access\n- *Issues*: Read & write\n - *Issue comment* (Issue comment created, edited, or deleted)\n- *Pages*: No access\n- *Pull requests*: Read & write\n - *Pull request* (Pull request opened, closed, reopened, edited, assigned, unassigned, review requested, review request removed, labeled, unlabeled, or synchronized)\n - *Pull request review* (Pull request review submitted, edited, or dismissed)\n - *Pull request review comment* (Pull request diff comment created, edited, or deleted)\n- *Repository contents*: Read & write\n - (no checkboxes)\n- *Single file*: No access\n- *Repository projects*: No access\n- *Organization members*: Read-only\n - *Team* (Team is created, deleted, edited, added to/removed from a repository)\n - *Member* (Collaborator added to, removed from, or has changed permissions for a repository)\n - *Membership* (Team membership added or removed)\n - *Organization* ( User invited to, added to, or removed from an organization)\n- *Organization projects*: No access\n- *Checks*: Read & Write\n - *Check run* (Check run created from the API)\n - *Check suite* (Check suite created from the API)\n\n#### Permission explanations\n\n*Repository metadata* will be read-only. Must be set to receive *Repository* events to automatically remove entries from our database when a repo is deleted.\n\n*Commit statuses* must be set to *Read & write* to report a testing status (this is the older version). Also must get *Status* events to integrate with CI systems that report their status via GitHub.\n\n*Issues* must be set to *Read & write* because pull requests are issues. *Issue comment* events must be enabled to get the \"bors r+\" comments. If *Issues* is set to Read-only, repos will end up with pull requests that are marked as simultaneously merged and opened.\n\n*Pull requests* must be set to *Read & write* to be able to post pull request comments. Also, must receive *Pull request* events to be able to keep the dashboard working, and must get *Pull request review* and *Pull request review comment* events to get those kinds of comments.\n\n*Repository contents* must be set to *Read & write* to be able to create merge commits.\n\n*Checks* must be set to *Read & write* to report a testing status (this is the newer version). Also must get *Check run* events to integrate with CI systems that report their status via GitHub.\n\n*Organization members* must be set to *Read only* to synchronize repository contributors and bors reviewers.\n\n### After you click the \"Create\" button\n\nGitHub will send a \"ping\" notification to your webhook endpoint. Since bors is not actually running yet, that will fail. This is expected.\n\nYou'll need the following values from your GitHub App for configuring bors-ng:\n\n- Private key (generate one and download the file)\n- OAuth credentials\n- ID (appears beneath the app logo and \"Owned by\" in the right hand column)\n\n### Internal app?\n\nGitHub Apps can be set as \"Internal\" or \"External\".\nWhen the App is set to be internal,\nthen whichever organization/user it belongs to will be the only one allowed to install it.\n\nThis setting can be chosen while first creating the app, or it can be changed afterward at one of these URLs (the switch is on the bottom of the page):\n\n* If the app is owned by an organization: `https://github.com/organizations//settings/apps//advanced`\n* If the app is owned by a user: `https://github.com/settings/apps//advanced`\n\nIf an \"External\" app is installed on any external repositories,\nthen the \"Make Internal\" button will be grayed out.\n\n## Step 2: Set up the server\n\nbors-ng is written in the [Elixir] programming language,\nand it uses [PostgreSQL] as the backend database.\nWhatever machine you plan to run it on needs to have both of those installed.\n\n[Elixir]: https://elixir-lang.org/\n[PostgreSQL]: https://postgresql.org/\n[docs on how to deploy phoenix apps]: https://hexdocs.pm/phoenix/deployment.html\n\nbors-ng is built on the Phoenix web framework, and they have [docs on how to deploy phoenix apps] already. Where you deploy will determine what the dashboard URL will be, which is needed in the previous steps, so this decision needs to be made before you can set up the Github App.\n\nYou'll need to edit the configuration with a few bors-specific variables.\n\n### Deploying on [Heroku] (and other 12-factor-style systems)\n\n[Heroku]: https://heroku.com/\n\nThe config file in the repository is already set up to pull the needed information from the environment, so you can configure bors by setting the right env variables and deploy the app from this repository into Heroku:\n\nYou can do using Heroku's one-button-deploy system:\n\n[![Deploy on Heroku](https://www.herokucdn.com/deploy/button.svg)](https://heroku.com/deploy)\n\nOr you can do it manually:\n\n**Note**: The `GITHUB_INTEGRATION_ID` is now called the App ID on GitHub.\n\n $ heroku create --buildpack \"https://github.com/HashNuke/heroku-buildpack-elixir.git\" bors-app\n $ heroku buildpacks:add https://github.com/gjaldon/heroku-buildpack-phoenix-static.git\n $ heroku addons:create heroku-postgresql:hobby-dev\n $ heroku config:set \\\n MIX_ENV=prod \\\n POOL_SIZE=18 \\\n PUBLIC_HOST=bors-app.herokuapp.com \\\n ALLOW_PRIVATE_REPOS=true \\\n COMMAND_TRIGGER=bors \\\n SECRET_KEY_BASE= \\\n GITHUB_CLIENT_ID= \\\n GITHUB_CLIENT_SECRET= \\\n GITHUB_INTEGRATION_ID= \\\n GITHUB_INTEGRATION_PEM=`base64 -w0 priv.pem` \\\n GITHUB_WEBHOOK_SECRET=\n $ git push heroku master\n $ heroku run 'POOL_SIZE=1 mix ecto.migrate'\n\n*WARNING*: bors-ng stores some short-term state inside the `web` dyno (it uses a sleeping process to implement delays, specifically).\nIt can recover the information after restarting, but it will not work correctly with Heroku's replication system.\nIf you need more throughput than one dyno can provide, you should deploy using a system that allows Erlang clustering to work.\n\n\n### Deploying using [Docker] (and compatible container orchestration systems)\n\n[Docker]: https://docker.com/\n\nPre-built Docker images are available at [Docker Hub](https://hub.docker.com/r/borsng/bors-ng/) for tags and the current `master` (as `bors-ng:latest`).\n\nThe Dockerfile in the project root can be used to build the image yourself.\nIt relies on [multi-stage builds](https://docs.docker.com/engine/userguide/eng-image/multistage-build/) as introduced in Docker 17.05,\nto generate a slim image without the Erlang, Elixir and NodeJS development tools.\n\nMost of the important configuration options should be set at runtime using environment variables, not unlike the Heroku instructions.\nAll the same recommendations apply, with some extra notes:\n\n- `ELIXIR_VERSION` can be set as a build-time argument. Its default value is defined in the [Dockerfile](Dockerfile).\n- `ALLOW_PRIVATE_REPOS` must be set at both build and run times to take effect. It is set to ` true` by default.\n- `DATABASE_URL` *must* contain the database port, as it will be used at container startup to wait until the database is reachable. [The format is documented here](https://hexdocs.pm/ecto/Ecto.Repo.html#module-urls).\n- `DATABASE_TIMEOUT` may be set higher than the default of `15_000`(ms). This may be necessary with repositories with a very large amount of members.\n- The database schema will be automatically created and migrated at container startup, unless the ` DATABASE_AUTO_MIGRATE` env. var.\n is set to `false`. Make that change if the database state is managed externally, or if you are using a database that cannot safely handle\n concurrent schema changes (such as older MariaDB/MySQL versions).\n- Database migrations can be manually applied from a container using the `migrate` release command. Example:\n `docker run borsng/bors-ng:latest /app/bors/bin/bors migrate`.\n Unfortunately other `mix` tasks are not available, as they cannot be run from compiled releases.\n- The `PORT` environment variable is set to `4000` by default.\n- `GITHUB_URL_ROOT_API` and `GITHUB_URL_ROOT_HTML` should allow you to connect bors-ng to an instance of GitHub Enterprise.\n Note: I've never actually used GitHub Enterprise, so I'm kinda guessing about what you'd need here.\n\n docker create --name bors --restart=unless-stopped \\\n -e PUBLIC_HOST=app.bors.tech \\\n -e SECRET_KEY_BASE= \\\n -e GITHUB_CLIENT_ID= \\\n -e GITHUB_CLIENT_SECRET= \\\n -e GITHUB_INTEGRATION_ID= \\\n -e GITHUB_INTEGRATION_PEM= \\\n -e GITHUB_WEBHOOK_SECRET= \\\n -e DATABASE_URL=\"postgresql://postgres:@db:5432/bors_ng\" \\\n -e DATABASE_USE_SSL=false \\\n -e DATABASE_AUTO_MIGRATE=true \\\n -e COMMAND_TRIGGER=bors \\\n borsng/bors-ng\n docker start bors\n\n### Deploying on your own cluster\n\nYour configuration can be done by modifying `config/prod.secret.exs`.\n\n## Optional step 3: make yourself an admin\n\nbors-ng offers a number of special functions for \"administrator\" users, including diagnostics and the ability to open a repo dashboard without being a reviewer.\n\nHowever, there's no UI for adding admins; you'll have to go into Postgres yourself to do it. There's two ways to do that:\n\nYou can do it from the iex prompt, like this:\n\n shell$ iex -S mix # or `heroku run bash -c \"POOL_SIZE=1 iex -S mix\"`\n iex> me = BorsNG.Database.Repo.get_by! BorsNG.Database.User, login: \"\"\n iex> BorsNG.Database.Repo.update! BorsNG.Database.User.changeset(me, %{is_admin: true})\n\nYou can do it from a PostgreSQL prompt like this:\n\n postgres=# \\c bors_dev -- or bors_prod\n bors_dev=# update users set is_admin = true where login = '';\n\n# Copyright license\n\nbors-ng is licensed under the Apache license, version 2.0.\nIt should be included with the source distribution in LICENSE-APACHE.\nIf it is missing, it is at .\n","has_starred","hub_user","notriddle","immutable_tags_settings",{"_72":11,"_73":74},"enabled","rules",[75],".*","is_automated","permissions",{"_79":17,"_80":11,"_81":11},"read","write","admin","user","storage_size",1607279282,"orgData",{"_87":88,"_89":90,"_91":92,"_93":29,"_94":95,"_96":97,"_98":99,"_100":101,"_102":103,"_104":105,"_106":97,"_107":97,"_108":17},"id","544eb308f962443a87ddd95fd39466d7","uuid","544eb308-f962-443a-87dd-d95fd39466d7","type","organization","orgname","full_name","bors-ng","location","","company","never break the build again","profile_url","https://bors.tech/","date_joined","2017-09-16T00:09:03.177919Z","gravatar_url","https://www.gravatar.com/avatar/13ca0cdb06325453c7ee877c9c0b7df9?s=80&r=g&d=mm","gravatar_email","badge","is_active","recentTags",[111],{"_112":40,"_113":114,"_115":116,"_87":117,"_118":119,"_46":136,"_137":114,"_138":29,"_139":52,"_53":140,"_141":142,"_143":127,"_144":136,"_145":62,"_146":17},"content_type","creator",2162970,"full_size",150592914,139113906,"images",[120],{"_121":122,"_123":124,"_125":97,"_126":127,"_128":129,"_130":131,"_132":97,"_133":-5,"_134":116,"_59":62,"_135":-5},"architecture","amd64","digest","sha256:3bf7bfbcfc3f4c5456e92bbb689b01fb011fb4a0e617945ff66de4adb018a99d","features","last_pulled","2026-09-23T17:12:08.102448286Z","last_pushed","2021-07-23T01:12:31Z","os","linux","os_features","os_version","size","variant","2021-07-26T18:04:59.818407Z","last_updater","last_updater_username","media_type","latest","repository",11567967,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"routes/_layout.r.$namespace.$reponame.tags",{"_34":158,"_165":166,"_154":175,"_176":11},{"_36":159,"_38":160,"_41":42,"_43":44,"_45":11,"_46":47,"_48":49,"_50":161,"_53":31,"_28":29,"_54":55,"_56":40,"_57":58,"_59":60,"_61":62,"_63":-5,"_64":58,"_65":66,"_67":11,"_68":69,"_70":162,"_76":11,"_77":164,"_82":29,"_83":84},[],[40],[52],{"_72":11,"_73":163},[75],{"_79":17,"_80":11,"_81":11},"tags",{"_167":60,"_168":-5,"_169":-5,"_170":171},"count","next","previous","results",[172],{"_112":40,"_113":114,"_115":116,"_87":117,"_118":173,"_46":136,"_137":114,"_138":29,"_139":52,"_53":140,"_141":142,"_143":127,"_144":136,"_145":62,"_146":17},[174],{"_121":122,"_123":124,"_125":97,"_126":127,"_128":129,"_130":131,"_132":97,"_133":-5,"_134":116,"_59":62,"_135":-5},[],"canDeleteTags","actionData","errors"]

borsng/mysqlnd

Tags for borsng/mysqlnd