microsoft / AL-Go

The plug-and-play DevOps solution for Business Central app development on GitHub
MIT License
274 stars 114 forks source link

Publish To Environment breaks CI/CD pipelines #798

Open gntpet opened 10 months ago

gntpet commented 10 months ago

Hey @freddydk,

I have just tried to use "Publish To Environment" to push changes to our 'PROD' environment.

image

Since that environment is not defined in the environment list & I have no environment secret defined, it takes me through "device login" path. Very smooth and handy image

Then, it deploys artifacts to the environment. All good here.

But, when my CICD process runs, it suddenly picks this PROD environment and tries to deploy to it. I never asked for it, and I have no setup for it in my AL go settings.

image

My Al-go-settings file looks like this:

{
  "type": "PTE",
  "templateUrl": "https://github.com/microsoft/AL-Go-PTE@preview",
  "treatTestFailuresAsWarnings": true,
  "doNotRunBcptTests": true,
  "enableCodeCop": true,
  "rulesetFile": "../al.ruleset.json",
  "companyName": "TNM Automated Test",
  "runs-on": "srs-eid",   
  "githubRunner": "srs-eid",
  "environments": [
    "SRSQA"
  ],
  "DeployToSRSQA": {
    "EnvironmentType": "SaaS",
    "EnvironmentName": "SRSQA",
    "Projects": "SRS.nl",
    "Branches": [
      "main"
    ],
    "SyncMode": "ForceSync",
    "ContinuousDeployment": true,
    "runs-on": "srs-eid"
  },
  "EnableTaskScheduler": true
}

Best Regards, Gintautas

mazhelez commented 10 months ago

Hey @gntpet

Using excludeEnvironments setting (see doc in AL-Go settings) will hopefully solve your issue.

freddydk commented 10 months ago

The reason for this is that GitHub creates the environment under environments when you run Publish to environment to that. excludeEnvironments as Maria says or using the DeployToSRSPROD, setting "ContinuousDeployment": false should solve this.

freddydk commented 10 months ago

It is counterintutive though that an environment used to publish once gets picked up for continuous deployment automatically - will investigate what we can do about that.

freddydk commented 9 months ago

I think this should be fixed by only allowing continuous deployment to environments, where a authcontext secret exists in either GitHub or the KeyVault. If no authcontext secret exists, the deployment will fail anyway and we shouldn't try in the first place.