Stream: t-release/triagebot

Topic: "do everything bot"


Pietro Albini (Feb 27 2020 at 12:36, on Zulip):

@simulacrum moving from the bisect-rustc topic

Pietro Albini (Feb 27 2020 at 12:36, on Zulip):

I would sort of like if triagebot becomes the place for most of our automation

Pietro Albini (Feb 27 2020 at 12:37, on Zulip):

like, a thing I'd love is a button somewhere so that team members can automatically get the deploy keys for github pages configured

Pietro Albini (Feb 27 2020 at 12:38, on Zulip):

or possibly a button "please open a PR filling my team repo details"

Pietro Albini (Feb 27 2020 at 12:39, on Zulip):

just bikeshedding... @rustbot / bot.rust-lang.org / rust-lang/bot?

simulacrum (Feb 27 2020 at 12:42, on Zulip):

I think rustbot, which is what we have now is fine

simulacrum (Feb 27 2020 at 12:42, on Zulip):

(possibly rust-bot if it's a GitHub app)

simulacrum (Feb 27 2020 at 12:42, on Zulip):

I would put it at either triage.r-lo or infra.r-l.o or so

simulacrum (Feb 27 2020 at 12:43, on Zulip):

It's not really a bot - that's not the main point

simulacrum (Feb 27 2020 at 12:43, on Zulip):

Just a helper

XAMPPRocky (Feb 27 2020 at 15:12, on Zulip):

@Pietro Albini I've been experimenting with GitHub Actions for these kinds of tasks, since they don't require any additional infrastructure, and you can use actions inline in your repo, so the behaviour and automation can be made to suit specific use cases. Right now I'm making a mdbook-deploy action to build and deploy mdbook projects to gh-pages as well experimenting with an action to automatically create personalised repositories for project groups from the template when someone adds a project to team.

Pietro Albini (Feb 27 2020 at 15:12, on Zulip):

iirc they didn't fix not being able to push to github pages from actions

Pietro Albini (Feb 27 2020 at 15:13, on Zulip):

that's why we still need deploy keys

Pietro Albini (Feb 27 2020 at 15:14, on Zulip):

I'd love to be able to stop using them, but well, unless they fixed it last week without updating the feedback issue we can't do that

XAMPPRocky (Feb 27 2020 at 15:14, on Zulip):

I know, I'm not saying it fixes that specific problem.

XAMPPRocky (Feb 27 2020 at 15:15, on Zulip):

or possibly a button "please open a PR filling my team repo details"

I was more talking about something like that.

simulacrum (Feb 27 2020 at 15:15, on Zulip):

I personally also find GHA somewhat painful to configure in a new repo (you need to copy a bunch of files and configure things, etc.)

Pietro Albini (Feb 27 2020 at 15:15, on Zulip):

@XAMPPRocky not sure how what you propose would fix the problem?

simulacrum (Feb 27 2020 at 15:15, on Zulip):

and for some of this it's just much easier to do with a webpage, I feel

Pietro Albini (Feb 27 2020 at 15:16, on Zulip):

I probably didn't explain myself clearly, but that suggestion was for people adding themselves in the repo for the first time (like icebreakers), to remove the need to clone the repo and run the add-person command

XAMPPRocky (Feb 27 2020 at 15:18, on Zulip):

@simulacrum There are templates provided by GitHub that have worked pretty well for me. https://github.com/actions/typescript-action

simulacrum (Feb 27 2020 at 15:20, on Zulip):

I don't personally think templates solve anything

simulacrum (Feb 27 2020 at 15:21, on Zulip):

like they're excellent to have

simulacrum (Feb 27 2020 at 15:21, on Zulip):

but the overhead is still too high

simulacrum (Feb 27 2020 at 15:21, on Zulip):

compared to pushing a button

XAMPPRocky (Feb 27 2020 at 15:29, on Zulip):

@Pietro Albini Right, what I'm saying that it's actually quite easy to do that through GitHub Actions (far easier than a button), and that we could do it in ways that are more intuitive to a GitHub workflow. Because you can have any action triggered by a webhook event.

For example you can create a workflow that triggers on every new comment in an pull request or an issue. That means we could do something like open a PR for the next icebreakers group and then anyone who puts "add me" in the pull request automatically gets added as a commit to that pull request.

XAMPPRocky (Feb 27 2020 at 15:32, on Zulip):

The problems with a button on a website is authentication, people either need to sign in to your github app to work, or you have to create a server based app storing the secret that makes the actual pull request. Where as with GitHub Actions we can store the secret in the repo itself.

simulacrum (Feb 27 2020 at 15:39, on Zulip):

I personally find GH actions sufficiently opaque that I'd prefer it to run on our own infra. That might be a lack of experience speaking, though.

simulacrum (Feb 27 2020 at 15:40, on Zulip):

e.g. for the PR/issue and "add me" I personally find that a bit less nice than a landing page that says 'join us by clicking [here].

simulacrum (Feb 27 2020 at 15:48, on Zulip):

Or maybe even just links on forge to it

XAMPPRocky (Feb 27 2020 at 16:07, on Zulip):

e.g. for the PR/issue and "add me" I personally find that a bit less nice than a landing page that says 'join us by clicking [here].

A landing page has to be designed and maintained, and advantage of a comment is it very low friction, both on the user and the integration side.

I personally find GH actions sufficiently opaque that I'd prefer it to run on our own infra. That might be a lack of experience speaking, though.

I definitely disagree that it's opaque, and I don't understand how it's not our own infra, it is what we're using in a lot of projects on rust-lang. Actions are entirely git based, so you can easily create and share your own infra, and fork and extend any of GitHub's infra. For example I made the simple-ci action to simplify the CI for some projects in the rust-lang org where the CI script is always the same cargo build && cargo test. And this is the entire script.

const process = require('process')
// Third Party libraries
const actions = require('@actions/core')
const exec = require('@actions/exec')
// Configuration
const checkFmt = actions.getInput('check_fmt') || false

async function main () {
  try {
    if (checkFmt) {
      try {
        await exec.exec('which', 'rustfmt')
      } catch {
        await exec.exec('rustup', ['component', 'add', 'rustfmt'])
      }
      await exec.exec('cargo', ['fmt', '--check'])
    }

    await exec.exec('cargo', ['build', '--workspace'])
    await exec.exec('cargo', ['test', '--workspace'])
  } catch (error) {
    console.log(error)
    process.exit(1)
  }
}

main()
Pietro Albini (Feb 27 2020 at 17:11, on Zulip):

Where as with GitHub Actions we can store the secret in the repo itself.

I definitely don't want to store sensitive secrets on github actions if we can avoid it

XAMPPRocky (Mar 15 2020 at 00:22, on Zulip):

Sorry I don't think I was clear I meant the secrets that you can store on a repo. https://help.github.com/en/actions/configuring-and-managing-workflows/creating-and-storing-encrypted-secrets

Pietro Albini (Mar 15 2020 at 09:41, on Zulip):

@XAMPPRocky yep I'm aware of those, still, I'd prefer not to store the secrets on gha

XAMPPRocky (Mar 15 2020 at 10:35, on Zulip):

@Pietro Albini Can you expand on your motivation? Because without that, it seems like a bit of FUD to me.

Pietro Albini (Mar 15 2020 at 10:35, on Zulip):

in private

Pietro Albini (Mar 15 2020 at 10:35, on Zulip):

(pinged you on discord)

Pietro Albini (Mar 15 2020 at 10:47, on Zulip):

clarified with erin in private (btw, this is related to the team repo specifically, most other repos can use gha secrets just fine)

Last update: Apr 03 2020 at 18:20UTC