ArgoCD Continuous Integration (CI)

 

Troubleshooting CI checks

You can click on the "Details" link next to the failed step to get more information about the failure.

Failed GitHub Action

To read more about The GitHub actions are configured in ci-build.yaml.

Can I retrigger the checks without pushing a new commit?

Since the CI pipeline is triggered on Git commits, there is currently no (known) way on how to retrigger the CI checks without pushing a new commit to your branch.

If you are absolutely sure that the failure was due to a failure in the pipeline, and not an error within the changes you committed, you can push an empty commit to your branch, thus retriggering the pipeline without any code changes. To do so, issue

git commit -s --allow-empty -m "Retrigger CI pipeline"
git push origin <yourbranch>

Why does the build step fail?

First, make sure the failing build step succeeds on your machine. Remember the containerized build toolchain is available, too.

If the build is failing at the Ensure Go modules synchronicity step, you need to first download all Go dependent modules locally via go mod download and then run go mod tidy to make sure the dependent Go modules are tidied up. Finally, commit and push your changes to go.mod and go.sum to your branch.

If the build is failing at the Build & cache Go code, you need to make sure make build-local runs successfully on your local machine.

Why does the codegen step fail?

If the codegen step fails with "Check nothing has changed...", chances are high that you did not run make codegen, or did not commit the changes it made. You should double-check by running make codegen followed by git status in the local working copy of your branch. Commit any changes and push them to your GH branch to have the CI check it again.

A second common case for this is, when you modified any of the auto generated assets, as these will be overwritten upon make codegen.

Generally, this step runs codegen and compares the outcome against the Git branch it has checked out. If there are differences, the step will fail.

See What checked-in code is generated and where does it come from? for more information.

Why does the lint step fail?

Your code failed to lint correctly, or modifications were performed by the golangci-lint process.

  • You should run make lint, or golangci-lint run on your local branch and fix all the issues.

  • If you receive an error like, File is not `goimports`-ed (goimports), the file is not formatted correctly. Run gofmt -w $file.go to resolve this linter error.

Why does the test or e2e steps fail?

You should check for the cause of the failure in the check's detail page as described above. This will give you the name of the test that has failed, and details about why. If your test are passing locally (using the virtualized toolchain), chances are that the test might be flaky and will pass the next time it is run. Please retrigger the CI pipeline as described above and see if the test step now passes.

Updating The Builder Image

Login to Docker Hub:

docker login

Build image:

make builder-image IMAGE_NAMESPACE=argoproj IMAGE_TAG=v1.0.0

Public CD

Every commit to master is built and published to ghcr.io/argoproj/argo-cd/argocd:<version>-<short-sha>. The list of images is available at https://github.com/argoproj/argo-cd/packages.

Note

GitHub docker registry requires authentication to read even publicly available packages. Follow the steps from Kubernetes documentation to configure image pull secret if you want to use ghcr.io/argoproj/argo-cd/argocd image.

The image is automatically deployed to the dev Argo CD instance: https://cd.apps.argoproj.io/

Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more