GITEA_TOKEN environment variable isn't being recognized

[thepaperpilot]

Description of the bug

I have my content store setup to use @indiekit/store-gitea, but when I try making a post I get this error:

I'm using docker, and running docker exec indiekit env returns all the environment variables set within the container, and I've verified GITEA_TOKEN (the name of the environment variable per the store-gitea documentation) is set correctly.

Steps to reproduce

No response

Expected behaviour

No response

Environment

• Indiekit version: 1.0.0-beta.18
• @indiekit/store-gitea: { "instance": "https://code.incremental.social/", "user": "thepaperpilot", "repo": "pages", "branch": "master" }

Additional context

No response

[paulrobertlloyd]

Thanks for reporting this issue. It could be down to a number things; Indiekit, Docker, Gitea API. I tested this against my own token on gitea.com and it still works.

It seems as though the Forgejo API still accepts a token in the Authorization header, so Indiekit’s integration should still be compatible.

Do you have a way to safely test using your token directly as the token option in the plugin config? For example:

"@indiekit/store-gitea": {
  user: "thepaperpilot",
  repo: "pages",
  branch: "master",
  token: "my_secret_token"
}

That would eliminate process.env.GITEA_TOKEN not being found. If that still doesn’t work, we can try to investigate other ideas.

Relatedly, I’m absolutely lost in the weeds of Gitea/Codeburg/Forgejo forks; is Gitea the right name to use for this plugin now, or is it misleading?

[paulrobertlloyd]

Also, #634 might be related to this issue, so check to see if your token has a $ in it somewhere.

[thepaperpilot]

I added the token to the config directly and still received the same error. The token is hexadecimal, so no $s.

[paulrobertlloyd]

Okay. Might it be possible for me to create a test repo on https://code.incremental.social to eliminate there being any differences between instances?

[thepaperpilot]

absolutely. It's open to signups

[paulrobertlloyd]

Tested locally, without Docker, and was able to successfully save code to your instance: https://code.incremental.social/paulrobertlloyd/indiekit-sandbox/commit/f85a93f7fdeab2c3c0493ee2d18b66698b1f5aad

That would suggest this might be a Docker thing. Have to say, I find Docker to be a complete mystery, but will see if I can set it up again on my computer and try the same.

Are you using a particular Docker Compose/other configuration that you can share?

[thepaperpilot]

My docker compose includes a lot of services, but these are the indiekit-related ones:

  indiekit_db:
    image: mongo
    restart: always
    container_name: indiekit_db
    volumes:
      - indiekit_db_data:/data/db
    environment:
      - MONGO_INITDB_ROOT_USERNAME=indiekit
      - MONGO_INITDB_ROOT_PASSWORD=${INDIEKIT_DB_PASSWORD}
      - MONGO_HOSTNAME=indiekit_db
  indiekit:
    build: ./indiekit
    restart: always
    container_name: indiekit
    environment:
      - SECRET=${INDIEKIT_SECRET}
      - PASSWORD_SECRET=${INDIEKIT_PASSWORD_SECRET}
      - MONGO_URL=mongodb://indiekit:${INDIEKIT_DB_PASSWORD}@indiekit_db:27017
      - GITEA_TOKEN=${INDIEKIT_GITEA_TOKEN}
      - S3_ACCESS_KEY=${INDIEKIT_S3_ACCESS_KEY}
      - S3_SECRET_KEY=${INDIEKIT_S3_SECRET_KEY}
    labels:
      - traefik.enable=true
      - traefik.http.routers.indie.rule=Host(`indie.incremental.social`)
      - traefik.http.routers.indie.entrypoints=websecure
      - traefik.http.routers.indie.tls.certresolver=myresolver
      - traefik.http.services.indie.loadbalancer.server.port=3000

The labels at the end are just for routing and are unlikely to be the issue here. I'm not sure what would be causing it to not recognize the token when its in the config itself, docker or not. I'll fiddle with it later as well and let you know if I discover any insights.

[thepaperpilot]

Oh, I just realized; since the image uploads are working for me now, the store-s3 plugin must be correctly reading my environment variable credentials. So perhaps the two plugins do something differently.

[thepaperpilot]

@paulrobertlloyd I discovered the issue, and it was another configuration issue on my end. I'd included a trailing slash in the gitea instance property, and the code did not like that.

So I'm all set now (yay! thanks for the project!), but it'd probably be best to handle the trailing slash case so others don't run into the same issue.

[paulrobertlloyd]

Ah, that’d explain it! Have updated how the API request URL is created in 3a83733, hopefully that should make this a bit more robust.