Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi-pipelines: origin needs to be factored into freight id #2240

Closed
krancour opened this issue Jul 5, 2024 · 2 comments · Fixed by #2241
Closed

multi-pipelines: origin needs to be factored into freight id #2240

krancour opened this issue Jul 5, 2024 · 2 comments · Fixed by #2241

Comments

@krancour
Copy link
Member

krancour commented Jul 5, 2024

I set up two warehouses today where both looked for manifests in the same repo -- one using includePaths: [microservice-a] and the other using includePaths: [microservice-b].

Because the most recent commit had changes to both paths (it was an initial commit), both warehouses calculated the same Freight name and only one piece of Freight was produced. That piece of Freight had origin: {kind: Warehouse, name: microservice-a}.

The result is that Stages requesting Freight from origin: {kind: Warehouse, name: microservice-b} could not have that request fulfilled.

If we factor origin into each piece of Freight's deterministically calculated name, these conflicts will not occur.

cc @hiddeco for a sanity check.

@hiddeco
Copy link
Contributor

hiddeco commented Jul 5, 2024

For the record: I think your reasoning adds up here.

I did wonder for a bit if there are any potential downsides of the "deduplication" not happening (i.e. two Warehouses producing the same Freight because they ship the same items), but I think we are at a point where it has become clear that Freight is unique to its origin, and not necessarily just the contents.

@krancour
Copy link
Member Author

krancour commented Jul 8, 2024

This was fixed in #2241, but remained open because the feature branch its in has not been merged to main yet.

#1680 is the epic that we'll close when that happens.

I think we can safely close this as completed.

@krancour krancour closed this as completed Jul 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants