Closed actuarysailor closed 5 months ago
@actuarysailor this repo is not using a fine grained token, its using a classic PAT. I have not made changes to it since the fine-grained token was implemented.
I'll merge this PR and test, but the last time this change was made i had to revert it because it was causing all tests to not use the branch under testing, but the main branch.
@actuarysailor this repo is not using a fine grained token, its using a classic PAT. I have not made changes to it since the fine-grained token was implemented.
I'll merge this PR and test, but the last time this change was made i had to revert it because it was causing all tests to not use the branch under testing, but the main branch.
It should use the branch under testing. However, don't merge it yet then, there are specific GitHub variables that maybe the action are not using correctly, let me check that before you merge. Can you approve the action to run>?
@actuarysailor this didn't seem to work - the action integration test was not triggered at all.
I'm sorry, but I cannot spend more time on this project. To be blunt, I don't need any of these features, so this is not a priority for me. If you need these features, I suggest forking the action, maintaining them in your own fork, and using your fork. If you end up maintaining the fork publicly, I might even archive this and just use yours.
I'm sorry you've spent this effort without getting it merged.
@actuarysailor this didn't seem to work - the action integration test was not triggered at all.
I'm sorry, but I cannot spend more time on this project. To be blunt, I don't need any of these features, so this is not a priority for me. If you need these features, I suggest forking the action, maintaining them in your own fork, and using your fork. If you end up maintaining the fork publicly, I might even archive this and just use yours.
I'm sorry you've spent this effort without getting it merged.
@andrewthetechie - Well then, can you send me any of the advanced repo settings etc. that I can not see so I can start with a repo identical to yours? or you could make a copy of yours etc. and
I don't have the time to reverse engineer all the governance and controls you have, or set up my own.
There aren't any advanced repo settings or anything you'd be missing from a fork. It's just a very basic github repo based on https://github.com/jacobtomlinson/python-container-action
Everything is maintained by the actions in .github/workflows.
If you're forking my code, you just have to maintain the MIT license on it, but if you need another license I'd be happy to discuss releasing the terms of my existing license as long as the new license isn't restrictive or closed.
@andrewthetechie - ok, I really don't think you are using a fine grained token though: it is still in beta.
Yes, I said that above
@actuarysailor this repo is not using a fine grained token, its using a classic PAT.
Yes, I said that above
@actuarysailor this repo is not using a fine grained token, its using a classic PAT.
@andrewthetechie - yes, I'm just trying to figure out what is different. When I run in my repo, I only get those errors when I try the new fine grained tokens, not the legacy ones...
Are you sure they didn't upgrade yours to fine grained automatically? All of my legacy ones were listed under fine grained. I had to create new legacy ones.
@andrewthetechie - need your help with configuring it to be self-maintained. Your release please automations still update stuff to use your name.
This way you don't have to worry about your test results being different post pull-request. This will solve issues for PRs from any forks that could potentially break your repo.
@andrewthetechie - you will see, this PR will fail the action test because of the permission and token differences despite no changes to the actual code in repo.
However, once you merge this PR it will pass in your repo... Then if I re-open the PR you said caused issues, that passed the test before merge but failed once merged, it will now start failing for the same issue.
Defining this action to use pull_request_target is the only way you will be able to ensure that your TEST properly identifies bugs both before and after merges. Otherwise, does not matter whose fork you use, mine or other people, the test will provide false positives/negatives because of how GitHub works...
I am assuming your repo is using a fine grained token now, because otherwise that last PR would have worked post merge..