Label to title

[samwaseda]

I did more or less what @liamhuber said here

[samwaseda]

I'm testing it here but so far it's not working.

[liamhuber]

I'm testing it here but so far it's not working.

I'm on mobile, but it looks like the test location needs the "uses" clause nested inside the regular "steps" field; take a look at pyiron workflow or some of the actions reusable workflows for something to mimic

[samwaseda]

The other ones use yml files from .github/workflow/xyz.yml. Should I make a file there?

[liamhuber]

No, just invoke it like a usual action invocation:

actions/.github/workflows/release.yml

Line 21 in 606379c

- uses: actions/checkout@v4

[liamhuber]

Showing my work: I grabbed the github.token recommendation from ChatGPT, but it looks super familiar and I was hunting for that answer, so I think I read it in the docs. The shell lines are just copy-pasted from the other places we use the shell.

[liamhuber]

Alternatively, we could take the token as explicit input like the checkout action does:

actions/.github/workflows/push-pull.yml

Lines 179 to 181 in 606379c

	- uses: actions/checkout@v4
	with:
	token: ${{ secrets.DEPENDABOT_WORKFLOW_TOKEN }}

[liamhuber]

Actually, that's probably wiser -- we might get away with secrets being automatically inherited when we use the action inside the pyiron org, but it is just generally a great action and we want it available globally.

[liamhuber]

pyiron/elaston#18 (comment)

But don't merge yet, let's try from a repo outside the org to make sure the secret still passes

[liamhuber]

Hmm, runs but doesn't fail hard when I try it in my own namespace: https://github.com/liamhuber/action-test/actions/runs/10382454910/job/28745564689?pr=2

EDIT: runs but doesn't work, critically

[liamhuber]

Even with the token getting passed in, I'm still getting the same access error from outside the org:

 {
  "message": "Resource not accessible by integration",
  "documentation_url": "https://docs.github.com/rest/issues/issues#update-an-issue",
  "status": "403"
}

I've got to go to bed, but I'll be available tomorrow at some point in the AM to take another look

[liamhuber]

Ahh, ok, the problem was on the side of the repo, not the side of the action! I hadn't configured the repo to allow actions to modify stuff:

With that done it's working fine!

I want to try:

• Reverting the token-input changes to see if it works
  • If it then needs to inherit secrets, using the token to pass only the secret it needs seems preferable (and in line with actions/checkout)
• Use step outputs instead of the deprecated set-output

[liamhuber]

@samwaseda, nice! I'm happy with it. The problems I was running into last night were entirely on my end -- repo settings were off. I fixed the deprecation warning and added some comments to help users. Take a look at my changes, but from my end this is good, working as intended, and useful.

Extensions that make sense to me:

• Proof-check that the label doesn't already start with "[TAG]" -- right now, if you add the "patch" label to a title already starting with "[patch]" you get "[patch] [patch] ...". IMO, ideal behaviour would be for it to not act if the title already starts with the new prefix, and to fail if it starts with a different prefix
• Run the action in reverse, i.e. if the label is updated and it starts with a "[TAG]", add the corresponding label
• Make it flexible, so that tags are space-separated input with defaults of "patch major minor" so it can add arbitrary title prefixes

But with the core functionality working well, IMO those can be left out of this PR

[samwaseda]

Yeah I thought about the first point. For the second point I got the feeling that it’s more important to have the tag in the title than as a label so I guess we can leave it for now.