pkim-auro
commented
6 years ago ok i'm trying to simulate this doing the checkout myself as :
git clone --branch 1.0.0 https://github.com/pkim-auro/helloworld.git and it works, but it's detached. Now when i try to forge build or forge deploy it uses the default profile which looks like the one from the demo with the branch.replace (and it errors out since i'm not ON a branch). i tried forge --profile=stable build with no luck.
I ended up having to run git checkout -B master origin/master on each repo which had a service yaml where the head was detached.
Feel like the timing is a little off. I know we talked earlier about it scanning other repos but even when i was in a single repo with no requires: it would fail as it scanned other repos which were detached and service.yaml wouldn't function because they too were in detached states. After writing this up, I feel like it should be a bug that a different service.yaml profile parse fails and causes the current repo to fail. Separate ticket?
I don't like the workaround but i am treating it in a completely separate folder (aka non dev environment) when I clone all the repos and reset their current commit to master. just have to make sure i don't try to push it back up on accident...
example service which fails. (even if i'm in a completely different repo with no dependencies)
profiles:
stable:
endpoint: /helloworld/
max_memory: 0.5G
max_cpu: 0.5
canary:
endpoint: /helloworld/
weight: 10
max_memory: 0.25G
max_cpu: 0.25
default:
name: {{branch.replace('/', '-').replace('_','-')}}
endpoint: /preview/helloworld/{{branch}}/
max_memory: 0.25G
max_cpu: 0.25
branches:
master: stable
Per discussion please consider adding the following features:
1) ability to specify a single specific version in a "requires", 2) ability (for a specific profile) to directly set the image forge uses rather than having it compute it's own name
Example: Requires:
Forge Build from this repo would then look for the repos in the directory tree. Then clone / pull and checkout the appropriate tag within the repo and now rather than compute the image name (since it was provided) it just deploys the manifest with the provided image.
Caveat 1: we didn't talk about was how to handle "latest" or null on the image tag. Null is current behavior as it just specifies repo. My specific use case would most likely not use it, but I suppose we would need to differentiate behavior between recalculate latest and use "latest" image found in the repo. Maybe:
Caveat 2: I wasn't sure how the filesystem is scanned or how sophisticated the clone/pull logic was. In my use case, I can assume all the images come from the same private git repo and same private docker organization.
Thanks!