gratitude 2023-03-08 | Slack Archive

lread18:03:42

When one works alone, one can sometimes be ignorant that one is doing odd things. Example 1: Even when I had write privs to a GitHub repo, I'd work from a fork. I happened to notice @borkdude not working this way. And realized, doh, I could be working off branches in those GitHub repos. Example 2: For GitHub repos I maintain, I seem to only trigger CI tests when a user creates a PR and on a PR merge to the main branch. But again our @borkdude helped me to see that triggering CI tests on commits (from all forks and branches) will be helpful to folks to verify their work before submitting a PR. I'm not sure why I did not see these things, but whatevs, I see them now. Thanks @borkdude!

💜 24

lread19:03:34

Anyhoo, in addition to being thankful, 2nd reason for sharing is that maybe others are doing the same odd things as I was. Just trying to spread the learnings!

lread14:03:23

Now... if I can just tell GitHub Actions to stop triggering a build for the same thing twice. It builds once for PR and another time for push. If I figure it out, I'll report back.

Björn Christensson20:03:38

@UE21H2HHD is it that when you open a PR, you don't want it to kick off twice?

borkdude20:03:56

yes

lread20:03:39

Ya, I think I've got something working that avoids this now.

🎉 2

Björn Christensson20:03:52

I don't know much about gh workflow but I wonder if this is what is needed

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

☝️ here we might be able to skip out one of those... for instance.. do not add opened to to this list

borkdude20:03:34

but you do want to build PRs that are opened for branches from forks

lread20:03:37

I've removed synchronize and left in the default opened and reopened.

lread20:03:52

Yeah, for that we also trigger on push: . But the push: and the pull_request: synchronize triggered twice for the same commit.

👍 2

borkdude20:03:37

ok, let's hope this works

lread20:03:56

The experiments continue. I'll report back when I have extreme success.

Björn Christensson20:03:15

> extreme success Haha love that expression ⭐

lread20:03:55

Ya, been using that for a while, it often gets a smile!

Björn Christensson20:03:24

is that martin fowler extreme? I'll steel it anyways!

lread20:03:37

As in extreme programming? Nope. Just extra fantastic awesome success.

🙌 2

Björn Christensson20:03:25

Yep, that was where my programming brain went 😉

lread20:03:35

I guess, it could be Fowler/Beck extreme, if you want it to be. There are no rules.

Björn Christensson20:03:02

Sounds like a win!

lread20:03:49

Hey how arduous is it to setup a 2nd github org? I might want to test in the small with a forked repo. It is easy peasy lemon squeazy?

borkdude20:03:09

you can maybe abuse clj-easy for this

lread20:03:21

Ah, excellent idea.

lread20:03:24

And if I do reach extreme success we might leave it around to serve as one way to go about this.

lread21:03:52

Hmmm. A detail: Forgot (or did not realize) is that workflows are not automatically run on forks and have to be enabled.

lread04:03:33

> Ya, I think I've got something working that avoids this now. My idea did not work, will continue to explore.

2023-03-08

Channels