Remote sources, Accounts and the Web UI

General Discussions
1

Hi,

I have begun to experiment with Agola using a microk8s deployed cluster based on the example/kubernetes/simple yml resources.

For my use case I wish to initiate user direct runs using a locally cloned repo. I discovered while experimenting with the platform that creating accounts seemed to be limited to only working when a remote repo was available so I did a go build to get an agola cmd line binary and ran the following commands to create what I believe is an unlinked account.

export AGOLA_IP=`kubectl get service agola -o json | jq -r .spec.clusterIP`
export AGOLA_PORT=`kubectl get service agola -o json | jq -r ".spec.ports[].port"`
./agola user create -n karl -u http://$AGOLA_IP:$AGOLA_PORT
./agola.exe user token create -n karl -u http://$AGOLA_IP:$AGOLA_PORT -d --token "admintoken" -t default

However after doing this it became apparent that I cannot login to the web UI as I have no remotes configured.

The functionality hints that the presence of a real remote might not be needed if I used only userdirect runs, however I don’t appear to be able to use the web UI in that case to view any pipeline results if I was to use agola in a headless manner.

So my question is, can I use the full functionality of the agola UI without a remote ?

Thanks,
Karl

2

@karlmutch I suggest you to just create a simple gitea and add it as a remote source: it’s very lightweight and easy and it’s explained here: Demo | Agola

Currently agola login requires a remote source since it’s the fastest way and you usually have at least one remote source. Other auth methods like local password auth needs to be implemented: Add local auth · Issue #23 · agola-io/agola · GitHub (but require a lot of work to make them secure adding 2fa, email confirmation etc…).

3

@sgotti More on the Kubernetes setup. I went through the instructions and setup the gitea server, then went through and changed the gitea setup to use the appropriate Host IP for the service. After this I then added the remotesource successfully to agola.

I also modified the ConfigMap for the agola service as well to use the expose IP for the Kubernetes ‘simple’ service.

After performing these steps the web UI still shows the message that there are no remote sources defined. I looked at the logs for the agola pod and can see the addition of the remote source with no other messages, except for raft and compaction messages.

I added the -d option to the agola pod to try and get additional logging but none appeared. Are there any additional options for enabling debug logging on the agola pod ?

Thanks,
Karl

4

@karlmutch I don’t think you’ll find anything from a debug level log.

Does an agola remotesource list shows the remote source?

If yes, it’s a web ui issue. You can enable chrome/firefox console (F12) and open the Network tab and see if there’s a call to https://youragola/api/v1alpha/remotesources and the response contents and provide it here.

5 
$ agola.exe remotesource list --gateway-url http://$AGOLA_IP:8000 -d
2cad0da9-f6a9-4e65-89b1-995608de1f5f: Name: gitea

When I use the browser the initial page is accessible on port 8000 and displays its contents appropriately. However when the request is made by the web app back to the kubernetes gateway for the remote sources it tries to use the internal TCP/IP port, 30002, the config file for the Kubernetes simple looks to be oriented towards the docker style deployment. I modified the configmap and reloaded the pod and things have cleared up.

Thanks for all the help,
Karl

6

@karlmutch glad you resolved it.

I think you had to change the apiExposedURL value, right?

The comment above it says: # Change this to the exposed "agola" service IP. Also the port should be changed and probably the comment should be improved.

7

@sgotti I changed apiExposedURL, webExposeURL wherever they appeared.

The user direct run command ran but did not give any specific information about the jobs etc that were created. I used the run command to dummy up a simple test as follows:

version: v0

runs:
  - name: run
    runtime:
      type: pod
      arch: amd64
      containers:
        - image: debian:stretch
    steps:
      - run:
        command: ls -alcrt

I manually started a direct run as follows:

$ agola--token 772b6f7e0421a50dd87a782a2cc188eeacb052a5 --gateway-url http://$AGOLA_IP:8000 directrun start            
2020-03-05T09:12:52.890-0800    INFO    git-save/save.go:204    created temporary index: .git/gitsave-index-b9a8149a-da38-4bf5-8bf9-5af8f16439a7
2020-03-05T09:12:52.923-0800    INFO    git-save/save.go:215    updating files already in the index
2020-03-05T09:12:53.354-0800    INFO    git-save/save.go:221    adding untracked files
2020-03-05T09:12:53.730-0800    INFO    git-save/save.go:234    writing tree file
2020-03-05T09:12:53.747-0800    INFO    git-save/save.go:239    tree: e8f1aa31936014f18939b6c41acf5efa856579db
2020-03-05T09:12:53.747-0800    INFO    git-save/save.go:241    committing tree
2020-03-05T09:12:53.750-0800    INFO    git-save/save.go:246    commit: 0042de732a7736240512478bc4f3909fa07b2179
2020-03-05T09:12:53.750-0800    INFO    git-save/save.go:248    updating ref
2020-03-05T09:12:53.752-0800    INFO    cmd/directrunstart.go:185       pushing branch
2020-03-05T09:13:02.618-0800    INFO    cmd/directrunstart.go:204       starting direct run

Using the Web UI I cannot see the output from ls command but the Run has a status of ‘Success’ ?

I also do not know how to use the log command as it is requesting information that the userdirect start is not showing such as the mandatory runid, taskid ?

8

@karlmutch Probably ls output is empty. Try with another command like env.

you can use agola run list to get the runs or just get them from the ui: the run id can be seen with the chrome/firefox inspector network (we should also show it somewhere in the ui) while the task id is already shown.