Reorder book summary

[erlend-sh]

No description provided.

[tigleym]

LGTM! Thanks!

[erlend-sh]

@orhun could this summary file be excerpted from future formatting & linting checks? It's not like like the other .md files.

Also we seem to still be running build checks on .md files?

[orhun]

@orhun could this summary file be excerpted from future formatting & linting checks? It's not like like the other .md files.

Right now, we're supposedly ignoring *.md files, do you want this file to be included in build checks or something else? I didn't quite get it.

Also we seem to still be running build checks on .md files?

It is weird. The "checks" tab shows 0 so I guess it is being excluded from builds?

Unlike #231:

Also, I'm not sure what "Waiting for status to be reported" means, but I found this.

Either way, build checks for this PR seems to be not run so I assume this is an issue with GitHub. Can somebody with write access check if this button is shown:

It is highly unlikely but maybe clicking this will clear the "Expected — Waiting for status to be reported" message. Not really sure.

---

One last thing: I replicated this PR on my fork and build checks didn't run: orhun#2

[tigleym]

I suspect this action is causing the checks to not go through: "Create and Publish Github Release". Interestingly, it also happens on my own fork of the repo (and orhun's it seems).

In particular: this error Error: ⚠️ GitHub Releases requires a tag. I don't totally understand why a local PR would trigger this action vs. one from a forked repo (at least this is what I've observed from the PRs with successful checks here).

Some digging around I found this: softprops/action-gh-release#20

[orhun]

I suspect this action is causing the checks to not go through: "Create and Publish Github Release". Interestingly, it also happens on my own fork of the repo (and orhun's it seems).

In particular: this error Error: ⚠️ GitHub Releases requires a tag. I don't totally understand why a local PR would trigger this action vs. one from a forked repo (at least this is what I've observed from the PRs with successful checks here).

Some digging around I found this: softprops/action-gh-release#20

Yes, I noticed this as well. Pretty weird behavior. I don't know why it runs "on its own" when there is not tag created either.

Maybe we should consider switching to a more stable action for uploading release assets, such as upload-release-action.

(Although I don't know if it is related to the issue we're having here.)

[tigleym]

Yes, I noticed this as well. Pretty weird behavior. I don't know why it runs "on its own" when there is not tag created either.

I read that create will also trigger workflows for newly created branches: https://docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#create. I'm not sure if not specifying a branch here is causing the workflow to run when any new branch is created.

Maybe we could do something like:

on:
  create:
    branches:
      - 'release*'
    tags:
      - 'v*'

EDIT: Okay the above approach didn't seem to do anything.

Another thing we could try is instead of running on create we could do it on push?

Maybe we should consider switching to a more stable action for uploading release assets, such as upload-release-action.

Definitely worth looking into!

[orhun]

I read that create will also trigger workflows for newly created branches: docs.github.com/en/actions/learn-github-actions/events-that-trigger-workflows#create. I'm not sure if not specifying a branch here is causing the workflow to run when any new branch is created.

Exactly! Good catch 🐟

Another thing we could try is instead of running on create we could do it on push?

That's definitely going to solve the "running on its own" issue I think. I always used push for CD workflows in my projects and every time it worked fine. I totally overlooked that release workflow was using create in this case 😦

Maybe we should consider switching to a more stable action for uploading release assets, such as upload-release-action.

Definitely worth looking into!

Can I make this changes and submit a PR if you're not already working on this? 🐻

[tigleym]

Can I make this changes and submit a PR if you're not already working on this? 🐻

I haven't worked on it. So it would be great if you could do that! 🙏

[erlend-sh]

@orhun could we temporarily disable whatever check is blocking this just to get it merged?

[orhun]

@orhun could we temporarily disable whatever check is blocking this just to get it merged?

Checks in the actual repository are not being run for pull requests. Only the workflows in your forked repository (at the time of PR commit - 0d4a515) are checked. So you can disable the workflows by updating your erlend-sh-patch-1 branch. But, I don't think that's the reason why we can't merge because there seems to be a merge conflict.

I can solve the merge conflict and try to merge the PR for you, if you want 🐻

[erlend-sh]

I can solve the merge conflict and try to merge the PR for you, if you want 🐻

Yes please! 🙏

[orhun]

I resolved the conflict, but still couldn't merge because of this message:

Then I decided to go into repository settings and saw that we have the main branch protected and it was requiring some status checks to be passed before merge:

But the problem is, we don't run these checks for *.md files. So we're stuck in a dilemma 🙂

Should I remove those settings or temporarily disable the exclusion of markdown files? (I'd go with 1️⃣st option since this might cause other problems in the future) What do you think? @erlend-sh

[erlend-sh]

1️⃣ 👍