You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This script will create a cloud based development environment (Business Central SaaS Sandbox) for your project.
46
48
All apps and test apps will be compiled and published to the environment in the development scope.
47
49
The script will also modify launch.json to have a "Cloud Sandbox (<name>)" configuration point to your environment.
@@ -52,8 +54,6 @@ if (Test-Path (Join-Path $PSScriptRoot "NewBcContainer.ps1")) {
52
54
Write-Host-ForegroundColor Red "WARNING: The project has a NewBcContainer override defined. Typically, this means that you cannot run a cloud development environment"
Copy file name to clipboardExpand all lines: .github/RELEASENOTES.copy.md
+138-3Lines changed: 138 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -1,3 +1,133 @@
1
+
## v4.0
2
+
3
+
### Removal of the InsiderSasToken
4
+
5
+
As of October 1st 2023, Business Central insider builds are now publicly available. When creating local containers with the insider builds, you will have to accept the insider EULA (https://go.microsoft.com/fwlink/?linkid=2245051) in order to continue.
6
+
7
+
AL-Go for GitHub allows you to build and test using insider builds without any explicit approval, but please note that the insider artifacts contains the insider Eula and you automatically accept this when using the builds.
8
+
9
+
### Issues
10
+
- Issue 730 Support for external rulesets.
11
+
- Issue 739 Workflow specific KeyVault settings doesn't work for localDevEnv
12
+
- Using self-hosted runners while using Azure KeyVault for secrets or signing might fail with C:\Modules doesn't exist
13
+
- PullRequestHandler wasn't triggered if only .md files where changes. This lead to PRs which couldn't be merged if a PR status check was mandatory.
14
+
- Artifacts names for PR Builds were using the merge branch instead of the head branch.
15
+
16
+
### New Settings
17
+
-`enableExternalRulesets`: set this setting to true if you want to allow AL-Go to automatically download external references in rulesets.
18
+
-`deliverTo<deliveryTarget>`: is not really new, but has new properties and wasn't documented. The complete list of properties is here (note that some properties are deliveryTarget specific):
19
+
-**Branches** = an array of branch patterns, which are allowed to deliver to this deliveryTarget. (Default [ "main" ])
20
+
-**CreateContainerIfNotExist** = *[Only for DeliverToStorage]* Create Blob Storage Container if it doesn't already exist. (Default false)
21
+
22
+
### Deployment
23
+
Environment URL is now displayed underneath the environment being deployed to in the build summary. For Custom Deployment, the script can set the GitHub Output variable `environmentUrl` in order to show a custom URL.
24
+
25
+
## v3.3
26
+
27
+
### Issues
28
+
29
+
- Issue 227 Feature request: Allow deployments with "Schema Sync Mode" = Force
30
+
- Issue 519 Deploying to onprem environment
31
+
- Issue 520 Automatic deployment to environment with annotation
32
+
- Issue 592 Internal Server Error when publishing
33
+
- Issue 557 Deployment step fails when retried
34
+
- After configuring deployment branches for an environment in GitHub and setting Deployment Branch Policy to **Protected Branches**, AL-Go for GitHub would fail during initialization (trying to get environments for deployment)
35
+
- The DetermineDeploymentEnvironments doesn't work in private repositories (needs the GITHUB_TOKEN)
36
+
- Issue 683 Settings from GitHub variables ALGoRepoSettings and ALGoOrgSettings are not applied during build pipeline
37
+
- Issue 708 Inconsistent AuthTokenSecret Behavior in Multiple Projects: 'Secrets are not available'
38
+
39
+
### Breaking changes
40
+
41
+
Earlier, you could specify a mapping to an environment name in an environment secret called `<environmentname>_EnvironmentName`, `<environmentname>-EnvironmentName` or just `EnvironmentName`. You could also specify the projects you want to deploy to an environment as an environment secret called `Projects`.
42
+
43
+
This mechanism is no longer supported and you will get an error if your repository has these secrets. Instead you should use the `DeployTo<environmentName>` setting described below.
44
+
45
+
Earlier, you could also specify the projects you want to deploy to an environment in a setting called `<environmentName>_Projects` or `<environmentName>-Projects`. This is also no longer supported. Instead use the `DeployTo<environmentName>` and remove the old settings.
46
+
47
+
### New Actions
48
+
-`DetermineDeliveryTargets`: Determine which delivery targets should be used for delivering artifacts from the build job.
49
+
-`DetermineDeploymentEnvironments`: Determine which deployment environments should be used for the workflow.
50
+
51
+
### New Settings
52
+
-`projectName`: project setting used as friendly name for an AL-Go project, to be used in the UI for various workflows, e.g. CICD, Pull Request Build.
53
+
-`fullBuildPatterns`: used by `DetermineProjectsToBuild` action to specify changes in which files and folders would trigger a full build (building all AL-Go projects).
54
+
-`excludeEnvironments`: used by `DetermineDeploymentEnvironments` action to exclude environments from the list of environments considered for deployment.
55
+
-`deployTo<environmentName>`: is not really new, but has new properties. The complete list of properties is here:
56
+
-**EnvironmentType** = specifies the type of environment. The environment type can be used to invoke a custom deployment. (Default SaaS)
57
+
-**EnvironmentName** = specifies the "real" name of the environment if it differs from the GitHub environment
58
+
-**Branches** = an array of branch patterns, which are allowed to deploy to this environment. (Default [ "main" ])
59
+
-**Projects** = In multi-project repositories, this property can be a comma separated list of project patterns to deploy to this environment. (Default *)
60
+
-**SyncMode** = ForceSync if deployment to this environment should happen with ForceSync, else Add. If deploying to the development endpoint you can also specify Development or Clean. (Default Add)
61
+
-**ContinuousDeployment** = true if this environment should be used for continuous deployment, else false. (Default: AL-Go will continuously deploy to sandbox environments or environments, which doesn't end in (PROD) or (FAT)
62
+
-**runs-on** = specifies which GitHub runner to use when deploying to this environment. (Default is settings.runs-on)
63
+
64
+
### Custom Deployment
65
+
66
+
By specifying a custom EnvironmentType in the DeployTo structure for an environment, you can now add a script in the .github folder called `DeployTo<environmentType>.ps1`. This script will be executed instead of the standard deployment mechanism with the following parameters in a HashTable:
67
+
68
+
| Parameter | Description | Example |
69
+
| --------- | :--- | :--- |
70
+
|`$parameters.type`| Type of delivery (CD or Release) | CD |
71
+
|`$parameters.apps`| Apps to deploy | /home/runner/.../GHP-Common-main-Apps-2.0.33.0.zip |
72
+
|`$parameters.EnvironmentType`| Environment type | SaaS |
73
+
|`$parameters.EnvironmentName`| Environment name | Production |
74
+
|`$parameters.Branches`| Branches which should deploy to this environment (from settings) | main,dev |
75
+
|`$parameters.AuthContext`| AuthContext in a compressed Json structure | {"refreshToken":"mytoken"} |
76
+
|`$parameters.BranchesFromPolicy`| Branches which should deploy to this environment (from GitHub environments) | main |
77
+
|`$parameters.Projects`| Projects to deploy to this environment ||
78
+
|`$parameters.ContinuousDeployment`| Is this environment setup for continuous deployment | false |
79
+
|`$parameters."runs-on"`| GitHub runner to be used to run the deployment script | windows-latest |
80
+
81
+
### Status Checks in Pull Requests
82
+
83
+
AL-Go for GitHub now adds status checks to Pull Requests Builds. In your GitHub branch protection rules, you can set up "Pull Request Status Check" to be a required status check to ensure Pull Request Builds succeed before merging.
84
+
85
+
### Secrets in AL-Go for GitHub
86
+
In v3.2 of AL-Go for GitHub, all secrets requested by AL-Go for GitHub were available to all steps in a job one compressed JSON structure in env:Secrets.
87
+
With this update, only the steps that actually requires secrets will have the secrets available.
88
+
89
+
## v3.2
90
+
91
+
### Issues
92
+
93
+
Issue 542 Deploy Workflow fails
94
+
Issue 558 CI/CD attempts to deploy from feature branch
95
+
Issue 559 Changelog includes wrong commits
96
+
Publish to AppSource fails if publisher name or app name contains national or special characters
97
+
Issue 598 Cleanup during flush if build pipeline doesn't cleanup properly
98
+
Issue 608 When creating a release, throw error if no new artifacts have been added
99
+
Issue 528 Give better error messages when uploading to storage accounts
100
+
Create Online Development environment workflow failed in AppSource template unless AppSourceCopMandatoryAffixes is defined in repository settings file
101
+
Create Online Development environment workflow didn't have a project parameter and only worked for single project repositories
102
+
Create Online Development environment workflow didn't work if runs-on was set to Linux
103
+
Special characters are not supported in RepoName, Project names or other settings - Use UTF8 encoding to handle special characters in GITHUB_OUTPUT and GITHUB_ENV
104
+
105
+
### Issue 555
106
+
AL-Go contains several workflows, which create a Pull Request or pushes code directly.
107
+
All (except Update AL-Go System Files) earlier used the GITHUB_TOKEN to create the PR or commit.
108
+
The problem using GITHUB_TOKEN is that is doesn't trigger a pull request build or a commit build.
109
+
This is by design: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow
110
+
Now, you can set the checkbox called Use GhTokenWorkflow to allowing you to use the GhTokenWorkflow instead of the GITHUB_TOKEN - making sure that workflows are triggered
111
+
112
+
### New Settings
113
+
-`keyVaultCodesignCertificateName`: With this setting you can delegate the codesigning to an Azure Key Vault. This can be useful if your certificate has to be stored in a Hardware Security Module
114
+
-`PullRequestTrigger`: With this setting you can set which trigger to use for Pull Request Builds. By default AL-Go will use pull_request_target.
115
+
116
+
### New Actions
117
+
-`DownloadProjectDependencies`: Downloads the dependency apps for a given project and build mode.
118
+
119
+
### Settings and Secrets in AL-Go for GitHub
120
+
In earlier versions of AL-Go for GitHub, all settings were available as individual environment variables to scripts and overrides, this is no longer the case.
121
+
Settings were also available as one compressed JSON structure in env:Settings, this is still the case.
122
+
Settings can no longer contain line breaks. It might have been possible to use line breaks earlier, but it would likely have unwanted consequences.
123
+
Use `$settings = $ENV:Settings | ConvertFrom-Json` to get all settings in PowerShell.
124
+
125
+
In earlier versions of AL-Go for GitHub, all secrets requested by AL-Go for GitHub were available as individual environment variables to scripts and overrides, this is no longer the case.
126
+
As described in bug 647, all secrets available to the workflow were also available in env:_Secrets, this is no longer the case.
127
+
All requested secrets were also available (base64 encoded) as one compressed JSON structure in env:Secrets, this is still the case.
128
+
Use `$secrets = $ENV:Secrets | ConvertFrom-Json` to get all requested secrets in PowerShell.
129
+
You cannot get to any secrets that weren't requested by AL-Go for GitHub.
130
+
1
131
## v3.1
2
132
3
133
### Issues
@@ -23,9 +153,14 @@ All these actions now uses the selected branch in the **Run workflow** dialog as
23
153
24
154
### New Settings
25
155
26
-
-`UseCompilerFolder`: Setting useCompilerFolder to true causes your pipelines to use containerless compiling. Unless you also set `doNotPublishApps` to true, setting useCompilerFolder to true won't give you any performance advantage, since AL-Go for GitHub will still need to create a container in order to publish and test the apps. In the future, publishing and testing will be split from building and there will be other options for getting an instance of Business Central for publishing and testing.
156
+
-`UseCompilerFolder`: Setting useCompilerFolder to true causes your pipelines to use containerless compiling. Unless you also set `doNotPublishApps` to true, setting useCompilerFolder to true won't give you any performance advantage, since AL-Go for GitHub will still need to create a container in order to publish and test the apps. In the future, publishing and testing will be split from building and there will be other options for getting an instance of Business Central for publishing and testing.
27
157
-`vsixFile`: vsixFile should be a direct download URL to the version of the AL Language extension you want to use for building the project or repo. By default, AL-Go will use the AL Language extension that comes with the Business Central Artifacts.
28
158
159
+
### New Workflows
160
+
161
+
-**_BuildALGoProject** is a reusable workflow that unites the steps for building an AL-Go projects. It has been reused in the following workflows: _CI/CD_, _Pull Request Build_, _NextMinor_, _NextMajor_ and _Current_.
162
+
The workflow appears under the _Actions_ tab in GitHub, but it is not actionable in any way.
163
+
29
164
### New Actions
30
165
31
166
-**DetermineArtifactUrl** is used to determine which artifacts to use for building a project in CI/CD, PullRequestHandler, Current, NextMinor and NextMajor workflows.
@@ -161,7 +296,7 @@ Setting the repo setting "runs-on" to "Ubuntu-Latest", followed by running Updat
161
296
- Issue #273 Potential security issue in Pull Request Handler in Open Source repositories
162
297
- Issue #303 PullRequestHandler fails on added files
163
298
- Issue #299 Multi-project repositories build all projects on Pull Requests
164
-
- Issue #291 Issues with new Pull Request Handler
299
+
- Issue #291 Issues with new Pull Request Handler
165
300
- Issue #287 AL-Go pipeline fails in ReadSettings step
166
301
167
302
### Changes
@@ -276,7 +411,7 @@ Setting the repo setting "runs-on" to "Ubuntu-Latest", followed by running Updat
0 commit comments