Open charlesreid1 opened 6 years ago
Use config.json
to provide custom credentials with arbitrary names. Only caveat with running tests like these is, secrets need to get to UA somehow.
This is an issue now that we are opening pull requests - the commits are by @charlesreid1 but the PR is by @fp9695253
as user florence:
to redeploy:
to test, need to wait for some pull requests in organize or internal to be merged.
also, need to add mkdocs-material-dib to the whitelist
Got this working. We had a few additional tasks that we had to do:
/etc/sudoers.d/90-cloud-init-users
, which listed the permissions for the ubuntu user as having sudo access without a passwordflorence ALL=(ALL) NOPASSWD:ALL
on its own line to /etc/sudoers.d/90-cloud-init-users
/home/ubuntu/.ssh/authorized_keys
into /home/florence/.ssh/authorized_keys
so that we can ssh into beavo as user florencepip freeze > /tmp/freeze
as ubuntu user, pip install -r /tmp/freeze
as florence user/tmp/archie
were denying florence access?? it was group-writable, owned by the ubuntu group, and florence was a member of the ubuntu group. gave up and just chowned it as florence.We haven't actually tested whether commits are successfully created from the new account. For that, we'll have to wait for a submodule update.
Meanwhile, we can check that we can make commits as Florence Python...
Yes. Yes we can. https://github.com/dcppc/private-www/pull/99
Uncle Archie needs to run tests, and sometimes that requires credentials. So, let's talk credentials.
There are two sets of credentials that we're talking about here.
The first set of credentials are Uncle Archie's credentials - those are the Github credentials Uncle Archie uses internally to be able to access repositories (to clone them, run tests, mark things as working or broken, etc.). This requires Uncle Archie to be linked to a Github account with specific access levels. Those won't change. Those will be dependent on what we want to use Uncle Archie for (i.e., if it is for an organization, it should be using an account that can modify repositories needing CI testing). These are not the credentials we're interested in here.
The other set of credentials are test-specific credentials. Let's take an example: suppose we're testing a web application that has a user authentication layer that requires Github credentials to log in.
The easy way to test this might be to use Uncle Archie's existing credentials, but that's not a good general solution. We might want to check the web application authentication layer using multiple credentials, to test different groups or finer-grained permissions details.
We need a mechanism for providing Uncle Archie with secrets, in a secure manner.
Maybe we just create an Uncle Archie secrets file in the repo directory (that is in .gitignore)?