This is a really good initiative and definitely something that's needed! Well done!

I would like to see GitLab integration in Hatchet. This might not be as easy as GitHub since they don't have an equivalent to "GitHub Apps" in GitLab, but should still be relatively easy.

👋 it looks like these alpha release have been for some time, any chance of releasing 0.1.0?

Just started going through the Quickstart page on a fresh setup and encountering some issues.

While going through the CLI setup on https://docs.hatchet.run/getting-started/setup/quickstart/#creating-your-first-module, I made a mistake when running the config set-address command and wrote https instead of http. This worked without any errors, so perhaps some validation would be good there. I know that it will validate once you run hatchet init, but maybe an earlier check is worth it.

Another issue I encountered is that the Team I set up during the registration phase wasn't actually set up properly. I didn't notice that and ran through the Quickstart commands (with the incorrect https address):

cd smoke-test
hatchet config set-address https://localhost:8080
hatchet config set-api-token $token

The return of the set-api-token command did not include a default team (I only noticed later):

$ hatchet config set-api-token '$token'
Set the current api token successfully
Set the current organization as 6145face-98c9-4566-b0a6-582caf6cfe69

When I then run hatchet init it results in:

$ hatchet init
team id must be set: run [hatchet config set-team]

Running hatchet config set-team then results in an index out of range panic.

$ hatchet config set-team
panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
github.com/hatchet-dev/hatchet/cmd/hatchet-cli/cli.glob..func5(0x2154c60?, {0x22d8920?, 0x0?, 0x0?})
	/home/runner/work/hatchet/hatchet/cmd/hatchet-cli/cli/config.go:68 +0xda
github.com/spf13/cobra.(*Command).execute(0x2154c60, {0x22d8920, 0x0, 0x0})
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:920 +0x847
github.com/spf13/cobra.(*Command).ExecuteC(0x2153840)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:1044 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
	/home/runner/go/pkg/mod/github.com/spf13/[email protected]/command.go:968
github.com/hatchet-dev/hatchet/cmd/hatchet-cli/cli.Execute()
	/home/runner/work/hatchet/hatchet/cmd/hatchet-cli/cli/root.go:38 +0x7f
main.main()
	/home/runner/work/hatchet/hatchet/cmd/hatchet-cli/main.go:8 +0x17

When I later to go check on my teams in the UI it's empty, despite having created an initial team in the registering phase. So perhaps there's an issue creating the initial team?
After creating a team on the http://localhost:8080/organization/teams page, it no longer paniced when I ran hatchet init. It timed out since I had incorrectly configured the hatchet URL, but after changing the URL it worked fine.

It was hard to figure out what I needed to do to fix it, so I ended up deleting the ~/.hatchet/hatchet.yaml file and start over.

It looks like if I just run hatchet config set-api-token again it will fetch the team correctly the second time, but it uses the Hatchet URL from the JWT token, so even if the URL is incorrect, you won't know because the hatchet config set-api-token successfully fetches your Org and Team.

The URL in the token should either be used to populate the URL in the ~/.hatchet/hatchet.yaml file or it should at least throw a warning if it detects that they differ. Maybe use the ~/.hatchet/hatchet.yaml URL when looking up Org/Team and ignore the JWT URL?

Location

• Frontend
• hatchet-server
• hatchet-runner
• hatchet-runner-worker
• hatchet-temporal

Motivation

For a git-based workflow, changes can occasionally be unapplied on a master or main branch for a long time without visibility into whether those changes have been applied. Hatchet should periodically check that there are no unapplied changes on a branch, and alert the user if they exist.

Requirements

• Modify the OPA input for plan checks to determine when changes were last applied
• Create a default policy upon team creation that checks for unapplied changes

Additional Details

It should be possible to extend the auth mechanism to include more generic OIDC/OAuth integrations.

The config can look something like Dex OIDC connectors.

connectors:
- type: oidc
  id: google
  name: Google
  config:
    # Canonical URL of the provider, also used for configuration discovery.
    # This value MUST match the value returned in the provider config discovery.
    #
    # See: https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig
    issuer: https://accounts.google.com

    # Connector config values starting with a "$" will read from the environment.
    clientID: $GOOGLE_CLIENT_ID
    clientSecret: $GOOGLE_CLIENT_SECRET

    # Dex's issuer URL + "/callback"
    redirectURI: http://127.0.0.1:5556/callback

Location

• Frontend
• hatchet-server
• hatchet-runner
• hatchet-runner-worker
• hatchet-temporal

Motivation

Different logging formats are used between the chi logging middleware, GORM, and temporal. All of these packages accept a custom logger implementation, so it should be fairly simple to consolidate the loggers to allow for both JSON and readable logs.

Requirements

• Pass Hatchet logger to:
  • GORM
  • Chi logging middleware (might have to write custom logging middleware)
  • Temporal
• Make sure debug log level is respected (particularly by GORM)
• Print stack traces on error logs
• Update logging implementation to generate readable logs for testing/development

Additional Details

Hey @abelanger5 - I'm running Hatchet on my lab server, where hatchet-server is running behind Nginx, and over SSL, on https://hatchet.rudimk-infrastructure.com. I'm able to access the dashboard, and I'm also able to use the CLI to authenticate against this instance, but running hatchet init in the quickstart's smoke-test module results in the following error:

could not run init: rpc error: code = Unavailable desc = connection error: desc = "error reading server preface: http2: frame too large"

A quick search threw this comment up, with the OTEL Helm charts. Wondering if there's something one can tweak in terms of config to get past it? I have a feeling running this on Kubernetes will probably let me get past this anyway, but since I run personal infrastructure on Hetzner, still working on a solid K8s installer there.

For reference, my hatchet-server config:

runtime:
  port: 8080
  url: https://hatchet.rudimk-infrastructure.com
  runBackgroundWorker: true
  runRunnerWorker: false
  runTemporalServer: true
  runStaticFileServer: true
auth:
  cookie:
    domain: hatchet.rudimk-infrastructure.com
    insecure: false
fileStore:
  kind: local
  local: 
    directory: ./tmp/files
logStore:
  kind: file
  file: 
    directory: ./tmp/logs

Location

• Frontend
• hatchet-server
• hatchet-runner
• hatchet-runner-worker
• hatchet-temporal

Motivation

Drift detection currently alerts on if drift exists, but doesn't have any helpful messaging for tracking down which resources have drifted.

Requirements

• Modify the default OPA policy to parse the resource addresses of the drifted resources

Additional Details

Location

• Frontend
• hatchet-server
• hatchet-runner
• hatchet-runner-worker
• hatchet-temporal

Motivation

It should be possible to explore resources and view diffs of resource changes between applys. As a result, Hatchet should maintain a concept of each resource's state within a module.

Requirements

(TBD)

Additional Details

Description

If a monitor previously has a single module specified in it's matched modules array, and that module is deleted, the empty array will result in the monitor running against all modules.

Location

• Frontend
• hatchet-server
• hatchet-runner
• hatchet-runner-worker
• hatchet-temporal

Steps to reproduce

1. Create a module
2. Create a monitor and only select the previously created module
3. Delete the module
4. Monitor will now run against all modules

Additional Details