Spike: Git Branch Detection Outside Transform

Hey guys! So, we've got a bit of a head-scratcher here, and we're diving into the nitty-gritty of Git and its capabilities within our project. The main goal? To figure out if we can sniff out the current branch name outside the usual confines of our transform logic. This is crucial for a few reasons, as you'll see. Let's break down the challenge, the current situation, and what we're aiming to achieve.

The Core Challenge: Branch Awareness Beyond the Transform

So, here's the deal. @angelelli cooked up a neat little Python function that grabs the current branch name. The clever part? It uses this branch name to sneakily inject a site parameter into the Foundry execution. Think of it as a backdoor, but a useful one! This lets us dynamically configure things based on which branch we're working on. However, there's a catch, a big one. This function plays its magic within the transform logic. That's fantastic for certain things, but it limits us in a big way. We can't use this branch name information to parameterize the output location directly. That's a major bummer.

Imagine needing to send data to different storage locations based on your branch. Right now, that's tricky. You see, the transform logic handles the processing of data, but the output location (where the data goes) needs to be flexible. We want to be able to tell the system, "Hey, if you're on the 'develop' branch, send the output here; if you're on 'feature-x', send it over there." This is where the limitations of the current setup become apparent. We're essentially stuck inside a box when we need to be outside, giving instructions. We need to find a way to get that branch name information before the transform logic kicks in, so we can use it to determine where the results end up. This is where the experiment comes in. We are exploring the possibility of using some methods or git libraries to enable our functions to go beyond the limits.

The fundamental problem is that the branch name, as obtained by the current method, is only available inside the transform. We need it outside to do things like configure output paths. This is like trying to control a robot's destination (the output path) while only having access to its internal sensors (the branch name) once it's already started moving. We need a way to know the destination before the robot sets off. So, we're on a quest to figure out how to grab that branch name early on, making it available for setting up the output location and other crucial parameters before the transform runs. This is like giving the robot a GPS before it starts moving. We need a way for the system to "know" the branch name before the transform logic fires up, giving us the power to dynamically set up output paths and other configurations based on the branch. This is the heart of the spike.

Current Limitations and the Need for a Solution

The current limitation prevents us from fully leveraging the power of branch-specific configurations. The inability to parameterize the output location based on the branch name restricts our flexibility and makes it harder to manage different environments (like development, staging, and production) efficiently. For example, if we are working on a new feature on the feature branch. We would like the generated artifacts to be saved to a specific location for that branch. The current method can't handle such requirements. We need a way to grab the branch name and use it before the transformation begins. The whole idea is to create a dynamic environment by reading the branch name and customizing it. This is like providing flexibility to the system based on the branch's name.

This constraint has a knock-on effect on our overall development process. Without the ability to dynamically control output locations, we might have to resort to manual interventions or workarounds, which are prone to errors and consume valuable time. Manual interventions increase the chance of errors, and that is what we want to avoid. This is like trying to navigate without a map – you can get there eventually, but the journey will be more complicated and could lead to detours. We also want to simplify and streamline our workflow. We want to make sure the process is easy to use and maintain.

We need a method that will allow us to read the current branch name outside the transform logic. This will allow us to dynamically parameterize the output location. This is important for many reasons, including streamlined version control, and environment configuration. It also helps to keep our workflow smooth, as developers no longer need to manually change configurations. We need a more flexible and automated solution. This is where the spike comes in: we aim to develop a method that allows us to read the current branch name outside the transform logic.

Potential Solutions and Exploring New Avenues

@ShahimEssaid has some ideas brewing. The core concept involves looping through an array and calling the transform once per iteration. The cool part? The goal is to figure out how to get the branch name outside the transform so we can use it to parameterize the loop and, critically, the transform's output path. The core idea is to find a way to get the branch name outside of the transform logic and use that information. The team is going to use that information to customize the output paths.

So, the plan is to figure out a method, or maybe a library, that lets us grab that branch name before the transform even starts. The goal is to make that information available upfront so that we can do all sorts of cool things, like dynamically setting the output path based on the branch. The tricky part is ensuring that this information is available early enough in the process, before the transform logic gets fired up. This is a bit of a challenge, since the current system keeps the branch name