Open screid123 opened 1 year ago
Well now the script is working again. Unsure what changed. 🤷
I'll close this for now and re-open if it happens again.
Re-opening per Pantheon Support request. 👍
FWIW - I also see the same behavior happening on the build:env:create
command when it tries to do its "update issue" task:
Notice: ] Creating multidev pr-52 for site brcc-paid-search
Notice: ] Created Multidev environment "pr-52"
Notice: ] Enabled on-server development via SFTP for "pr-52"
Notice: ] Call GitHub API: POST repos///issues/52/comments
Error: ] Client error: `POST https://api.github.com/repos///issues/52/comments` resulted in a `404 Not Found` response:
{"message":"Not Found","documentation_url":"https://docs.github.com/rest"}
Error: ] error: Not Found. Http status code: 404
Notice: ] Caches cleared on pr-52.
Clearly something is weird with my GitHub workflow. I added another gist with the updated workflow: https://gist.github.com/screid123/febbf4f81a405ef54565f03c58beedab
Also getting the same error message on a CircleCI build, using the 'quay.io/pantheon-public/build-tools-ci:8.x-php8.1' image.
(Opened initially as a Pantheon Support Ticket
752761
)We are using GitHub Actions to deploy/sync our code from GitHub to Pantheon. The workflow we had setup was working fine for weeks up until Thursday, 2-Feb (as far as we can tell), and largely mimics the CircleCI orb/workflow.
The error happens during the “create multidev” step which happens on Pull Request if the environment doesn’t exist. From what I can tell, it seems the
terminus build:env:delete:pr
command is causing problems where it’s requesting info from GitHub but does not submit the correct URL:The URL is malformed as it does not contain the correct repo owner or name, e.g.-
https://api.github.com/repos///pulls?state=all
. When I comment out this command, the workflow runs “normally”, so it really seems to be isolated to thebuild:env:delete:pr
process.Here’s a gist with the raw log output, verbose output from
terminus build:env:delete:pr -vvv
, and a copy of the workflow file. I have even gone as far as adding in all the output vars set by the docker build-tools script used in CircleCI workflows, but the same result.