Error when evaluating 'strategy' for job 'Deploy'. .github/workflows/PublishToEnvironment.yaml

[SusanneJansTwoday]

Error when evaluating 'strategy' for job 'Deploy'. .github/workflows/PublishToEnvironment.yaml

[freddydk]

In the next version, AL-Go will display a warning when it encounters secrets, which might cause this kind of disruption.
Displaying the name of problematic secrets - but obviously not the values.
It is still up to the customer/partner to make sure that these secrets are not made available in AL-Go repositories.

[SusanneJansTwoday]

The customer has more than 700 repros, so it was not an option right now to change the setup - instead a temporary solution where all the org-secrets is overwritten in the algo repro with the same variables at repository-level has been created (with a dummy json-structure). This made the difference and now it's working again.
Thanks for your help, Fredddy - and for making the change to better warnings in the next version.

[freddydk]

It looks like you have spaces or newlines in your secrets (maybe the authcontext is not compressed)?

[SusanneJansTwoday]

I checked the json in the authcontext and no spaces or new lines :/
I also checked the values in postman to verify the app registration.

[freddydk]

It might be another secret or an organizational secret accessible in this repo.
Looking at

You can see that everywhere where there is a { or a } - they are masked as three *'s
This happens when the brackets are considered secrets - and then everything falls apart.

[SusanneJansTwoday]

Yes, I know that it, for some reason, is considered a secret, but I can see that I didn't write that explicitly in my question, sorry :)

I am working on a customer github-repository, so I will have to ask the admin to check the organizational secrets. Do you have an idea which other secrets the al-go needs to access on that level?

I also suspect that it could be a lack of sufficient permissions, so looking into that as well.

[freddydk]

It might be secrets made available to this repo that the repo doesn't use.
AL-Go doesn't use a lot of secrets, but if secrets with this content is made available to the github repo, they are masked as well.
You can see which secrets are made available to the repo under:

https://github.com/<owner>/<repo>/settings/secrets/actions

Ex.

The AL-Go repository should only have secrets available, which it needs.

[SusanneJansTwoday]

Thank you very much :) Will look into that.

[SusanneJansTwoday]

Hi Freddy

I have investigated the problem with customers admin of their github-repro.
It dosen't matter if we use an account with full admin permissions or with a pro-github subscription - we still have the same problems.
The customer did not want to recreate all their organisational secrets as you suggested. They are pretty sure they have well formed json as they are used all the time.
Instead the admin tried ruling them out the current repository - that did not change error-message either.

The problem with the environment being regarded as secrets starts immediatly after initiating the repo at step 1 - both with an organisational account and a personal account and with a free or pro subscription.

For your information the repro is internal as it is not possible to make it public as your walkthrough suggests.
Any more ideas? :)

[freddydk]

The issue comes from secrets being formatted as:

{
    "property": "value"
}

instead of

{"property":"value"}

Both are perfectly fine json - but the upper will cause issues.
I will do some investigations on whether we can avoid that.

[SusanneJansTwoday]

The issue starts at initiating the repro - before any secrets have been created, so in that case it must be some organisational secrets in the customer environment as you suggested. Thank you very much for looking into it anyway, Freddy :) I have also asked the customer to go through their variables again

[SusanneJansTwoday]

Hi again :)
I asked the customer to open temporaraly for the possibility to create public repros in their organisation - and this made the difference.
No problems with environments to be regarded as secret. So it seems that it is not possible to use ALGo for private repositories.

[freddydk]

AL-Go works just fine with private repositories as well. The difference is that all the organizational secrets are probably not available to public repositories, the secrets are probably set to be available to private repositories:

Secrets should only be available to the repositories who needs them.

[SusanneJansTwoday]

Okay, happy to hear that :)
In fact, the customer tried this at one point without success - but I do not know exactly how it was done, so I will inform him of this and ask him to try again.

[SusanneJansTwoday]

Okay, thank you - that sound good. The customer has a complex setup, that has to be changed first - so if you could publish the algo-changes or send them here it would be a great help.