As the error mentions please "Check the 'Rules' of this config repository"
- by default your config repo won't have rules/permissions to define
pipelines in any pipeline groups, environments etc. It is "secure by
default". You'll want to add a permission to do so.
e.g a blanket permission to
Based on the error message it looks like the clone URL you are using is
still an HTTPS one - to use SSH auth, you need to change it to an ssh URL,
e.g g...@github.com:gocd/gocd.git - it's an entirely different git
transport, not just an auth mechanism so the URL needs to change
accordingly :-)
If
Greetings colleagues,
I am trying to get into Yaml plugin (*gocd-yaml-config-plugin.jar* v.
*0.14.3-321*) with goCD v.23.3.0.
The plugin is able to receive the yaml file but always throws the same
error.
I am stuck with something pretty simple, like this:
format_version: 10
pipelines:
On Fri, Oct 27, 2023 at 1:13 PM vv-fork wrote:
> Thank you guys Sriram and Chad for answering those! Now it's getting
> clearer to me
>
> *I was able to connect using token. It's fine.*
>
> Though I* wasn't able* to connect using SSH Certificate.
> The key has been generated and installed:
>
Thank you guys Sriram and Chad for answering those! Now it's getting
clearer to me
*I was able to connect using token. It's fine.*
Though I* wasn't able* to connect using SSH Certificate.
The key has been generated and installed:
[image: unnamed.png]
it seems i set proper permissions:
[image:
Hi Chad,
I was just reading up on the changes for Kubernetes. Looks 1.24 moves to
containerd runtime images and we are still using DIND for our elastic
agents. That seems like it could be the culprit. I'll do some testing and
change our elastic agent images. Thanks for pointing that out.
On
Unfortunately the error message is a bit mysterious and useless. Which
agent image you are using? Anything special in the elastic agent pod spec
that might no longer work as expected on Kubernetes 1.24? (e.g use of
docker dind images)
Does the pod get created (and fail) if you look at the events
Just curious - were the errors/stack traces on failure essentially
identical before and after you upgraded your gocd and elastic agent plugin
versions?
On Thu, Oct 26, 2023 at 11:33 PM Kim Pham wrote:
> Hi Ashwanth,
>
> I checked the clusterrole of the service account it's using and it
>
Hi Ashwanth,
I checked the clusterrole of the service account it's using and it
basically has full access atm.
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
- - -- -
events [] [] [*]
A wild guess, anything changed on the service account side or a custom role
being added as part of the upgrade that is probably not allowing the gocd
plugin to create the pod?
Thanks,
On Thu, 26 Oct 2023 at 20:27, Kim Pham wrote:
> Hi All,
>
> We recently began to encounter issues where pods
Hi All,
We recently began to encounter issues where pods were unable to be
created. Nothing has changed in terms of GoCD server, agent, and
Kubernetes elastic agent plugin versions. However, we did notice that the
cluster went through an automatic upgrade and updated gke version to
1.24.14.
To add on to Sriram's comments, the use of the
github-oauth-authorization-plugin doesn't have any relationship with access
to repository content on GitHub - it simply allows people to log onto GoCD
using their Github identity, and optionally to have access to GoCD pipeline
groups mapped to GitHub
Please see:
https://docs.github.com/en/authentication/connecting-to-github-with-ssh
The gocd server runs as a particular user account. That user account needs
access to the ssh private keys used to authenticate with GitHub.
The go agent too needs the same access.
Assuming you are on Linux and
13 matches
Mail list logo
