Summary

Thank you to @keithchong for inspiring this fix.

Because ArgoCD applications are actually CRDs within the cluster where a team's ArgoCD instance was installed — all applications need have to be globally unique names. This is related to an ArgoCD issue requesting that ArgoCD applications be somehow project scoped, however the AppSource controller workflow should not wait for ArgoCD as a whole to be changed. Instead, the name of the ArgoCD Application will be <cluster>.<namespace>.<appsource.name>

Motivation

The appsource controller promotes its utility across multiple clusters, not just the one where the ArgoCD instance may be installed. With this updated syncPolicy we can ensure that applications are being made within their own namespaces, no matter what cluster they're being requested from.

Proposal

Create ArgoCD Applications with the name format <cluster>.<namespace>.<appsource.name>

Summary

Currently, users are pigeonholed into a garbage collection logic that deletes ArgoCD applications if a AppSource instance is deleted. Instead we would like to provide users the choice of deleting their ArgoCD applications if they include a finalizer in the annotation of their AppSource instance. They can also configure the finalizer to delete the ArgoCD application in different ways, as a background or foreground job, and whether the it should be a cascaded deletion that removes all resources referenced by the ArgoCD Application.

Motivation

Users will not forced into a specific workflow with the deletion of their AppSource instances

Proposal

Create a AppSource finalizer with foreground/background and cascade options that if present delete a AppSource instance's ArgoCD Application according to the options provided.

Default options to:

• Foreground
• Non-cascade deletion

Resources

• What are finalizers
• How to use finalizers

Summary

After completing #4, we should make Github Actions that run tests on the code being contributed from pull requests into this repo.

Motivation

We can ensure that code being merged into the master branch is stable and will not break future contributions being made to the project.

Proposal

Make a github action workflow that compiles all go files, lints them to make sure they're being formatted correctly, and then runs our testing framework on it to make sure that it interacts with ArgoCD correctly.

Summary

The readme documentation currently asks users to clone the Github Repo, this is tedious and most users will not want to do this. Instead reference the Installing AppSource section of the Getting started guide that references applying the single install manifest.

Add a finalizer field to AppSource custom resource that checks whether it has a deletion timestamp and finalizer — if both are true then we can delete ArgoCD Application.

Summary

Prior to being migrated to argoproj-labs, I was using my own controller image from on DockerHub. Now that we have our own quay.io repo we should instead be using the container image found there.

Proposal

These changes were already implemented in PR #30 but since features from that are still under review, I've made this issue, which will branch off of enhancement-29, remove the workflow changes and only keep the image changes.

Summary

Create a CI template and Issue template for enhancement proposals and bug reports

Notes

I already pushed the CI workflow to master which was a mistake, I'm creating an issue to go through a formal process of getting my workflow manifests reviewed.

Summary

We can utilize the pre-existing Notifications Engine to add a notifications field to the AppSource instance — so that Dev Teams can be notified about what is happening with their applications.

Motivation

Dev teams can stay informed about the state of their Applications through notifications.

Proposal

We add a optional notifications.channel field to the AppSource instance that will add an annotation to the Application within the Application Create Request made by the controller.

Here is an example AppSource instance manifest:

apiVersion: argoproj.io/v1alpha1
kind: AppSource
metadata:
  name: appsource-sample1
  namespace: my-project-us-west-2
spec:
  path: kustomize-guestbook
 # New Field
  notifications.channel: my_channel
  repoURL: https://github.com/argoproj/argocd-example-apps

This is the Application it would create:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    # New annotation
    notifications.argoproj.io/subscribe.on-sync-succeeded.slack: my_channel
. . .

Summary

Up until now, testing the AppSource controller has been done by spinning up a local (and then containerized) instance of the controller, and attempting to successfully use the sample manifests found in manifests/samples. For future contributions — it would be helpful to have a testing framework that tests the controller against a series of Admin ConfigMaps and AppSource instances, both correct and incorrectly defined ones.

Motivation

Having a uniform way of testing contributions to the project and assuring that every contribution is still meeting the level of correctness previous iterations passed.

Proposal

Make a script with argument path to a series of test environments (Admin configmaps and AppSource manifests) and expected results (ArgoCD resources that should have been created or errors that should have been popped up)

# Example path to test env
tests
| test1
| | config
| | | sample_admin_config.yaml
| | instances
| | | sample_appsource_instance1.yaml
| | | sample_appsource_instance2.yaml
| | expected
| | | projects
| | | | expected_argocd_project.yaml
| | | applications
| | | | expected_argocd_application1.yaml
| | | | expected_argocd_application2.yaml
| test2
| | config
| | | sample_admin_config.yaml
| | instances
| | | sample_appsource_instance.yaml
| | expected
| | | projects
| | | | expected_argocd_project.yaml
| | | applications
| | | | # Omitting an expected application/project means you expect it to throw an error

• Bool Flag --local determines whether the controller should be spun up as a local instance or as a deployment within the cluster.
• Bool flag --rolling determines whether the controller and ArgoCD env should be reset after every test or if the test script should just re-apply any manifests found between tests.

Resources

• Kubernetes EnvTest, more lightweight way of setting up cluster environment for testing

Summary

There is dead code in the AppSource type definitions and a bit of Kubebuilder boilerplate code left that should be removed.

The appsource module is currently named github.com/argoproj-labs/argocd-app-source, when the repo was migrated into argoproj-labs I changed the name of the repo to just appsource. With that change now Golang documentation site can't resolve the name github.com/argoproj-labs/argocd-app-source

Proposal

Use this rename module script to change the module name and replace all references to the import to the new module name github.com/argoproj-labs/appsource

Summary

The readme documentation currently asks users to clone the Github Repo, this is tedious and most users will not want to do this. Instead reference the Installing AppSource section of the Getting started guide that references applying the single install manifest.

AppSource typically going to be installed into it's own namespace in managed cluster (as opposed to controller plane cluster which host Argo CD). In order to simplify installation the resources defined https://github.com/argoproj-labs/appsource/blob/master/manifests/install.yaml should not have any namespace.

Instead of linking users to sample specs and configmaps just add a minimal one to the README doc

Summary

Currently the AppSource controller initialization logic requires that the AppSource configmap already exist, and it throws an error if it doesn't. Instead we should make the controller init logic wait for the AppSource configmap to exist before reconciling any AppSource events.

Motivation

This would provide users a smoother experience with the controller and would require less redeployments whenever users install the controller and don't have the AppSource config map configured yet.

Proposal

In the main() AppSource controller init logic found in main.go, try to find the AppSource ConfigMap but do not throw an error and exit the function if it does not exist already. Within the Reconcile function in pkg/controllers/appsource-controller.go, using a global boolean variable, we can check if the AppSource ConfigMap exists and set the boolean variable accordingly. We should check the global boolean variable before reconciling AppSource events and re-queue any events that occur prior to the AppSource configmap being set up.

The Argo maintainers recently agreed to require all Argoproj Labs project repositories to contain a SECURITY.md file which documents:

• Contact information for reporting security vulnerabilities
• Some minimal information about policies, practices, with possibly links to further documentation with more details

This will help direct vulnerability reporting to the right parties which can fix the issue.

You are free to use the following as examples/templates:

• Argoproj
• Workflows
• CD

Also, please note that in the future we are exploring a requirement that argoproj-labs projects perform a CII self-assessment to better inform its users about which security best practices are being followed.

Remove vendor from git history

The install CRD installation step as per "Getting started" doc fails due to the deployment namespace being set to "system" in the install.yaml

Should the line specifying namespace be removed from install.yaml and deployment.yaml?

Summary

It might be neat for users new to the repo to see the controller being used on a terminal when they're scrolling through the readme documentation. The gifs are already handy from the Medium article I wrote, all I need to do is upload them to this repo under the docs/assets directory and we should be good to go.

Summary

Create CONTRIBUTING.md file that explains how to pick up issues correctly.

Opening up and issues to add function comments to all the new files I made after reorganizing the repo :)

Summary

Currently, whenever the AppSource controller has to create a project it uses the single project spec template provided by the AppSource configmap. Instead of having a single template project, we could add several project "profiles" with a default fallback profile and then have developers annotate their AppSource instances with what profile they would like to use.

Motivation

Having a single project spec template forces admins to provide developers more ability than they might want to give. Having different spec profiles would allow admins and developers to get only what they need.

Proposal

Expand the AppSource configmap.data.project.template to be an array of "spec profiles" instead of a single template. Profiles are defined by the naming convention associated with that project (inspired by the already implemented namePattern logic).

Current (Single-Spec) AppSource configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-appsource-cm
  namespace: argocd
data:
  argocd.address: localhost:8080
  argocd.clientOpts: "--insecure"
  project.template: |
    namePattern: (?P<project>.*)-us-(west|east)-(\d.*)
    spec:
      # Project description
      description: Example Project

      # Allow manifests to deploy from any Git repos
      sourceRepos:
      - 'https://github.com/argoproj/*'

Proposed (Multi-Spec) AppSource configmap

apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-appsource-cm
  namespace: argocd
data:
  argocd.address: localhost:8080
  argocd.clientOpts: "--insecure"
  project.profiles: |
    - name: my-project
       namePattern: (?P<project>.*)-us-(west|east)-(\d.*) :
       spec:
         description: US West/East projects
         sourceRepos:
        - 'https://github.com/argoproj/*'
    - name: default
       namePattern : .*
       spec:
         description: Defualt project spec
         sourceRepos:
         - '*'

Summary

After the last enhancement that was pushed to master where the Condition object was re-written to follow Kubernetes convention. I realized that kubectl can not be used yet with AppSources.

Motivation

We would like to offer users the ability to use the kubectl wait --for=condition= option with appsources.

Proposal

Re-write the AppSourceCondition based on the pod conditions template and verify that kubectl wait works on it

Summary

Currently the appsource status subresource only holds error conditions. But in order to utilize kubectl's convenient mechanic that lets commands execute after a condition is met we should add successful conditions.

Motivation

kubectl commands can wait for certain conditions to be met, users might want to wait until an application has been successfully been created to do something like describing it.

Proposal

Add a new AppSourceConditionType called ApplicationCreationSuccess that is set after we successfully create an application. Also add a type called ApplicationExistsOk that is set when we reconcile the AppSource and it exists already.

Summary

AppSource users do not have access to the AppSource controller logs, however they still need to be informed about the status of the AppSource instances. We can use the AppSource.Status attribute to hold information about a given AppSource so that users can stay informed.

Motivation

Other resources have this same functionality, and providing users a experience that is consistent with pre-existing Kubernetes resources will improve the User Experience with the AppSource custom resource.

Proposal

Fill the attribute fields for pkg/api/appsource-types.go/AppSourceStatus to include conditions AppSource instances like lastTransitionTime, lastUpdateTime, reason, etc.

Check out the conditions that other Kubernetes resource utilize below.

References: https://github.com/bitnami-labs/sealed-secrets/blob/62cfb264f53e9a378ef1b8df051ac4d8a2af5da0/pkg/apis/sealed-secrets/v1alpha1/types.go#L59