On GitHub Enterprise Server, catalog and scaffold only support the latest version, not specific versions

[brant4test]

Describe the bug

When using a repo on GitHub Enterprise Server, the end-to-end process of using Terragrunt Catalog and Scaffold only works with the latest version and does not support specifying a version.

Steps To Reproduce

Steps to reproduce the behavior:

1. Use a repo on GitHub Enterprise Server.
2. Try specifying a version using //.?ref=v6.1.0 or ?ref=v6.1.0.
3. Run the terragrunt catalog command.
4. Observe that no code is scaffolded and the directory remains empty.

gruntwork@host:~/code/terragrunt/org/scaffold/infrastructure-live/auth-dev/us-west-2/dev/services/oauth/test6$ terragrunt catalog
22:57:39.954 WARN   Using `terragrunt.hcl` as the root of Terragrunt configurations is an anti-pattern, and no longer recommended. In a future version of Terragrunt, this will result in an error. You are advised to use a differently named file like `root.hcl` instead. For more information, see https://terragrunt.gruntwork.io/docs/migrate/migrating-from-root-terragrunt-hcl
22:57:40.027 INFO   Cloning repository "git::ssh://[email protected]/org/terraform-aws-iam.git//.?ref=v6.1.0" to temporary directory "/tmp/catalog695f4c4c6d6463743566424a5635626a386571387a6e4675326d38"
22:57:44.785 INFO   Found 10 modules in repository "git::ssh://[email protected]/org/terraform-aws-iam.git//.?ref=v6.1.0"
22:57:49.012 INFO   Run Scaffold for the module: "git::ssh://[email protected]/org/terraform-aws-iam.git//.?ref=v6.1.0//modules/attach-policy-to-role"
22:57:49.013 INFO   Scaffolding a new Terragrunt module git::ssh://[email protected]/org/terraform-aws-iam.git//.?ref=v6.1.0//modules/attach-policy-to-role to .

gruntwork@host:~/code/terragrunt/org/scaffold/infrastructure-live/auth-dev/us-west-2/dev/services/oauth/test6$ ls

gruntwork@host:~/code/terragrunt/org/scaffold/infrastructure-live/auth-dev/us-west-2/dev/services/oauth/test6$ tree .
.

0 directories, 0 files

Expected behavior

The scaffolding process should work correctly when specifying a version, and code should be scaffolded into the directory.

Nice to haves

The terminal output is already included in the Steps To Reproduce section.

Versions

• Terragrunt version: v0.70.4
• Terraform version: v1.5.7
• Environment details : Ubuntu 24.04.1 LTS (GNU/Linux 6.8.0-51-generic x86_64)

Additional context

Example fixture: Similar to this example, but on GitHub Enterprise Server.

[brant4test]

Hi, @yhakbar / Team,

By the way, I would also like to inquire about the following questions. Thank you. : )

As shown in the diagram, I have configured three catalog URLs: U1, U2, and U3. terragrunt catalog found modules M1, M2, M3, ... M14. Here are my assumptions, and welcome your comments:

M1 and M2 are from U1.
M3 and M4 are from U2.
M4 to M14 are from U3.

Here are the related questions:

A. As the number of URLs increases, how do we maintain the correspondence between M and U? In other words, how do we categorize and classify the modules? How can we make it easy for users to quickly identify the purpose of the modules? Should we rely on the module's own README? For example, M2 and M4 have the same name but come from different URLs.

B. I know that M1 and M3 are from the root directory of their respective repositories, while the other 10 should be located in the modules subdirectory. Can all the modules be used normally, i.e., without errors?

C. Why is the name of M1 not visible? How can we fix the display name?

D. If we need to add multiple catalog URLs, do we have to add each URL individually? Does it support glob patterns? Can we add an entire organization?

E. Once the number of catalog URLs increases, will it become slow? Can we load them in groups?

F. As the platform provider, can we offer catalog URLs in a centralized location for users? For example, in terragrunt.hcl, users would only need to specify a single repository from the platform. This repository would contain all the URLs the platform wants to provide to users. The platform would be responsible for maintaining this repository.

[brant4test]

Hi, @yhakbar / Team,

Does terragrunt scaffold support specifying dependencies? For example, in this use case:

1. A default scaffold that is used for the initial service setup in the addons repo with those default details.

2. Then all other addons would require that scaffold to already be run as a prerequisite requirement.

Thanks!

[yhakbar]

Hey @brant4test ,

These are quite a lot of questions! I'd encourage you to join our Office Hours during the next session to discuss your usage of catalog and scaffold at length.

Scaffold does not have anything out of the box for working with dependencies, but you're free to write templates that expect them. You can learn about custom templates here. It basically boils down to placing a .boilerplate directory where your module lives, and writing the configurations you want for Terragrunt to use when scaffolding out the module. Terragrunt will use those Boilerplate templates to drive the scaffolding process.

A. I would rely on the README files of the modules, yes. We may add additional styling in the future to make it clearer where modules originate from in the future.
B. Yup! They should be!
C. That value derives from the H1 heading of the README.md where the module lives.
D. Yes, right now you have to add each catalog URL individually. A common pattern used by Terragrunt users is to have an entrypoint catalog repository where all other modules are wrapped, and that pattern would make it so that you have less URLs to track.
E. That depends on a lot of factors, I can't guarantee how fast things will be on your server/workstation.
F. Yup! If you want enterprise support for this kind of thing, Gruntwork can help your organization get there.