New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update PANTHEON_SITE_NAME and TERMINUS_PLUGINS to prefer variables over secrets #470
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- `SSH_PRIVATE_KEY` A private key of a user which can push to Pantheon | ||
- `SSH_KNOWN_HOSTS` The result of running `ssh-keyscan -H codeserver.dev.$PANTHEON_SITE_ID.drush.in` | ||
- Add the following [variables to your GitLab repository](https://docs.gitlab.com/ee/ci/variables/#for-a-project): | ||
- `PANTHEON_TERMINUS_TOKEN` See https://pantheon.io/docs/terminus/install#machine-token (enable the _Mask variable_ checkbox) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. GitLab uses variables, but can mask the variable! TIL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming since they were varables already for gitlab, that there isn't any change needed in the gitlab action. yeah, looks that way since https://github.com/Lullabot/drainpipe/blob/main/scaffold/gitlab/PantheonReviewApps.gitlab-ci.yml doesn't specify variable or secret.
- Add the following [variables to your GitHub repository](https://docs.github.com/en/actions/learn-github-actions/variables#creating-configuration-variables-for-a-repository): | ||
- `PANTHEON_SITE_NAME` The canonical site name in Pantheon | ||
- `TERMINUS_PLUGINS` (optional) Comma-separated list of Terminus plugins to be available | ||
- Add the following [secrets to your GitHub repository](https://docs.github.com/en/codespaces/managing-codespaces-for-your-organization/managing-development-environment-secrets-for-your-repository-or-organization#adding-secrets-for-a-repository): | ||
- `PANTHEON_TERMINUS_TOKEN` See https://pantheon.io/docs/terminus/install#machine-token |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, this is the gitHUB section. The hunk below is the gitLAB section.
Error fail is
Is there something to clean out?? |
The secret is still set because it would fail on other PRs until this has been merged, so it's still showing as masked. When I remove it from this repo, after this is merged, we should be able to test confidently. |
Huh, so could the error be "incorrect secret" or something? Why would it say maximum mulitdevs? Feel free to disregard. I get that some fail is expected. |
This fail is happening in all of our PRs because we've exceeded the number of multidevs that Pantheon allows, I wish we could resolve that so we could truly test if this works or not. |
We could manually go in to the pantheon dashboard and delete the multidevs. (Might hit the quota again as people push new commits, but should relieve the issue temporarily.) |
Thanks! |
I removed the secret set in this repository so now we are only using the variable version which means that we can now see the word "drainpipe" in all the log output, hooray! |
Fixes #463
By setting PANTHEON_SITE_NAME as a secret, it will always be masked in job output, and you will be completely unable to use it in any action variable outputs, which is important if you want to pass the final Pantheon review URL to other subsequent jobs or workflows. Secrets were the only option at the time and GitHub variables at the organizaiton and repository level are relatively new and designed to hold non-secret information.
Documentation has also been updated.
I have added the variable to this repository as well, but since it's still set as a secret. It seems to be working, but since we still have the secret defined with the same value, it's getting masked still in job output.