Decommission circleci #5730
Decommission circleci #5730
Conversation
Signed-off-by: Jesús Benito Calzada <bjesus@vmware.com>
Signed-off-by: Jesús Benito Calzada <bjesus@vmware.com>
Signed-off-by: Jesús Benito Calzada <bjesus@vmware.com>
✅ Deploy Preview for kubeapps-dev canceled.Built without sensitive environment variables
|
beni0888
added
component/ci
| IMG_PREFIX: "kubeapps/" | ||
| # We use IMG_PREFIX_FOR_FORKS for development purposes, it's used when the workflow is run from a fork of the kubeapps repo | ||
| IMG_PREFIX_FOR_FORKS: "beni0888/" | ||
| # IMG_PLATFORMS: "linux/amd64, linux/arm64" | ||
| IMG_PREFIX_FOR_FORKS: "johndoe/" |
There was a problem hiding this comment.
I'd use the kubeapps-bot account instead, just in case:
| IMG_PREFIX_FOR_FORKS: "johndoe/" | |
| IMG_PREFIX_FOR_FORKS: "kubeapps-bot/" |
There was a problem hiding this comment.
I chose johndoe on purpose to make clear that it is something external to the Kubeapps organization. IMHO using kubeapps-bot could lead to confusion.
There was a problem hiding this comment.
your-dockerhub-username?
There was a problem hiding this comment.
Just asking: what if someone creates a your-dockerhub-username or a johndoe username in GitHub? Can they perform some undesired actions against our CI ? Or is it 100% safe ?
If there is a minimum risk of an undesired action, I'd rather go with something we have control over, like the bot user. If not, anything you suggest seems ok to me.
There was a problem hiding this comment.
I didn't understand exactly what you meant at first @antgamdia, as I thought the prefix is just used to push images when running in a forked repo, in which case it would fail anyway, but I think what you're suggesting is that maybe there is some way that us configuring a valid name that we don't own could lead to a privilege of that account? I don't see how, but I guess that's the point. Anyway, if so, why not give it an invalid name, like "" (assuming the <> are invalid).
Anyway, I think this point we're discussing here is probably not that important compared to the actual change, so still +1 from me, whatever you decide @beni0888 .
There was a problem hiding this comment.
@antgamdia I think you're not really understanding the meaning of that variable 🙂 Its only purpose is to allow you to push the images to a different workspace in DockerHub other than kubeapps, on which you (the user running the pipeline on its own fork) won't have permissions to push. It was added mainly for developing purposes, as I didn't want to push images from my fork to DockerHub at the early stages of the migration. But I cannot see any chance of performing an undesired action thanks to the value of this variable. BTW, I think that @absoludity suggestion of using your-dockerhub-username instead of johndoe is a good idea 🙂
There was a problem hiding this comment.
Ahhh, got it, got it. Thanks for the clarification! Sorry for the confusion :P
+1 to your-dockerhub-username or even your-container-registry-username
|
Hi @beni0888 . The checks here just have one error, which I assume is related to removing the circleCI pipeline? If so, is there anything stopping this from landing? I'd like to start the next release soon, but am keen for this to land before I do so. Thanks either way! |
No, there's nothing preventing us from landing this. I will apply your suggestion of using |
Signed-off-by: Jesús Benito Calzada <bjesus@vmware.com>
Also updates Hugo version (based on instructions in the release-process.md. Signed-off-by: Michael Nelson <minelson@vmware.com>
This PR aims to fix the failing full integration pipeline (which we need to pass for release). Also updates Hugo version (based on instructions in the release-process.md. Signed-off-by: Michael Nelson <minelson@vmware.com> <!-- Before you open the request please review the following guidelines and tips to help it be more easily integrated: - Describe the scope of your change - i.e. what the change does. - Describe any known limitations with your change. - Please run any tests or examples that can exercise your modified code. Thank you for contributing! --> ### Description of the change <!-- Describe the scope of your change - i.e. what the change does. --> Recent runs (from the past 6 days) of the [full integration pipeline](https://github.com/vmware-tanzu/kubeapps/actions/workflows/kubeapps-full-integration.yaml) have been failing. Looking for the differences, I could see that: - `chart-museum.sh` was failing to upload our custom apache chart to the chartmuseum instance, because... - `LOAD_BALANCER_IP` was set to `172.18.0.2`, which is the `DEX_IP`, whereas it should be set to the load balancer IP address (which has been created correctly), as it is in the last passing run. It's not doing this because... - The code that sets the `LOAD_BALANCER_IP` address does so conditionally based on the `GKE_BRANCH` environment variable, which is *blank*... so as far as that script can tell, it's not a GKE run. The reason that the `GKE_BRANCH` env var is blank is because... - In [#5730](https://github.com/vmware-tanzu/kubeapps/pull/5730/files#diff-164a87eb83a2101307c123bd6651d8f9355b51a995971d260038a1be44d6f6dbL19) the `GKE_BRANCH` env var was removed and replaced with `GKE_VERSION` everywhere *except* `e2e-test.sh` it seems. I assume this was just an oversight on our part. So this PR just finishes that change by renaming the var in `e2e-test.sh`. ### Benefits <!-- What benefits will be realized by the code change? --> Hopefully we can now pass the full integration pipeline. ### Possible drawbacks <!-- Describe any known limitations with your change --> ### Applicable issues <!-- Enter any applicable Issues here (You can reference an issue using #) --> - fixes # ### Additional information <!-- If there's anything else that's important and relevant to your pull request, mention that information here.--> Signed-off-by: Michael Nelson <minelson@vmware.com>
### Description of the change Following up #5730, this PR finally removes the old CircleCI config, as it hasn't been useful recently. ### Benefits No outdated files. ### Possible drawbacks N/A ### Applicable issues N/A ### Additional information N/A Signed-off-by: Antonio Gamez Diaz <agamez@vmware.com>
Description of the change
This commit decommissions the CircleCI pipeline and removes the temporary logic we added for development purposes from the GHA one.
Benefits
We get rid of the CircleCI pipeline and stick to the GHA one.
Possible drawbacks
None.
Applicable issues