You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we parallelized the PR generation in 1ce22e8 this broke the generation of a unique port number for Tilt. When run from github actions the loop index will always be 0 because the workflow replaces the repository list with a list with only one entry - so the port will be the same for every repository.
This is not a huge problem I guess, can always be edited manually .. but if we decide to go that route we should remove the incrementation code linked above because it'll just cause confusion.
Alternatively we can probably come up with a different way of doing this, if we want to keep the functionality. Keeping the port number in the metaqata would work, but require us to track it ..
In principle I have to say that I'm not in love with keeping the repository data in two places, the workflow file and the repositories config file.. maybe we could somehow read the matrix data for the workflow from the yaml file?
I have an idea to generate the port number based on the operator name. So it should be consistent, and non colliding, and small enough to be a valid port number.
When we parallelized the PR generation in 1ce22e8 this broke the generation of a unique port number for Tilt. When run from github actions the loop index will always be 0 because the workflow replaces the repository list with a list with only one entry - so the port will be the same for every repository.
This is not a huge problem I guess, can always be edited manually .. but if we decide to go that route we should remove the incrementation code linked above because it'll just cause confusion.
Alternatively we can probably come up with a different way of doing this, if we want to keep the functionality. Keeping the port number in the metaqata would work, but require us to track it ..
In principle I have to say that I'm not in love with keeping the repository data in two places, the workflow file and the repositories config file.. maybe we could somehow read the matrix data for the workflow from the yaml file?
https://stackoverflow.com/questions/63517732/github-actions-build-matrix-for-lambda-functions/63736071#63736071 seems to suggest this might be possible..
The text was updated successfully, but these errors were encountered: