[Question] How to update namedvalues only in specific higher environment ?

[DibyaRanjan1]

Release version

latest

Question Details

I have a scenario where I want update the prod API namedvalue. I have three environments dev,qa and prod. The namevalue is already present in all environments. Now I want to update only the prod namedvalue.

There is no changes in namedvalue folder because no change in dev config. How can I promote the change only to PROD ? Only prod.configuration file change, doesn't promote the change.

Expected behavior

Any way to promote environment-specific change to higher environments.

Dev --> No change
QA --> No change
Prod --> Change Needed

Actual behavior

promote environment-specific change to higher environments.

Dev --> No change
QA --> No change
Prod --> Change Needed

Reproduction Steps

1. Download all artifacts of the APIM dev environment using the extractor pipeline.
2. I want to change a prod namedvalue file which is already present. There is no change happened in dev and QA.
3. There is no git changes inside named values folder.
4. Added value in configuration.prod.yaml . This is the only git change. added the change to git commit and push.
5. As expected, named value for prod changes did not reflect in prod as no git changes inside named values folder.
6. What is the solution for this scenario?

[github-actions]

  Thank you for opening this issue! Please be patient while we will look into it and get back to you as this is an open source project. In the meantime make sure you take a look at the [closed issues](https://github.com/Azure/apiops/issues?q=is%3Aissue+is%3Aclosed) in case your question has already been answered. Don't forget to provide any additional information if needed (e.g. scrubbed logs, detailed feature requests,etc.).
  Whenever it's feasible, please don't hesitate to send a Pull Request (PR) our way. We'd greatly appreciate it, and we'll gladly assess and incorporate your changes.

[waelkdouh]

If you don't include the namedvalues in the configuration file then whatever is found in the artifacts folder will be promoted and it won't override anything.

Now if you want to completely ignore the namedvallues you can always use gitignore file as you promote as the publisher uses git when promoting. You may have to use different git branches for each environment as in one case you want to enforce the gitignore while in another you don't.

[DibyaRanjan1]

I think I did not put my query properly.

Suppose There is any existing API called Employee-API.

Dev backend Url:
https://dev.jll.com

QA backend URL:
https://qa.jll.com

Prod backend Url:
https://prod.jll.com

Now the API team tells, they need to change prod backend URL to https://newprod.jll.com.

How to do this with APIOPs ? What are things should be in git commit? As per my understanding, only configuration file changes should go to dev-->qa--> prod. But It does not have any namedvalues folder change. Do we need to forcefully make the file commit in the same git commit ?

[waelkdouh]

In this case you would maintain two separate configuration files with one for QA and another for prod. Then you would update the namdvalue in the production configuration which will get picked up by the publisher. Since you wouldn't update anything in the QA configuration file, nothing will change there.

[DibyaRanjan1]

Yes that is my expectation but It not working. It seems it considers configuration file changes only if actual API or named values changes are also part of the same commit. Could you check this ? Only configuration file changes do not reflect the changes in the Azure APIM instance. It seems , It ignores it.

[waelkdouh]

Ah I see what you are saying. You mean you only modified the value in the configuration file. I don't think the publisher picks that up. You will have to republish everything.

@guythetechie i now we had support for this scenario but then we rolled it back to only pick up changes from the artifacts folder only. Can you shed some light on that?

[DibyaRanjan1]

republishing will be scary. We have 800+ apis . It may take hours to republish. If anything goes wrong, due to republishing, it will cause a huge loss to the business.

I think, this can be fixed by considering the configuration .yaml file changes even if there are no changes in the repo.

[guythetechie]

Sorry, this isn't a supported scenario. As @waelkdouh said, you have to republish everything. The publisher doesn't consider configuration file changes.

To support what you're asking for, we'd need to detect that configuration changed, read the previous configuration version, identify the difference, and publish just that difference. Keep in mind that for the publisher, configuration doesn't just come from the YAML. It also comes from environment variables and other sources.

As a workaround, I would make a trivial change in the namedValueInformation.json file. Set the value there to something bogus. The publisher would pick up just this change, override it with the new configuration value, and publish. Completely understand that this is not ideal though.

[DibyaRanjan1]

Thank you. Let me know once It's picked up for the next release.

[waelkdouh]

Thank you. Let me know once It's picked up for the next release.

Hey @DibyaRanjan1 what do you mean by let me know when it's picked up for the next release? We are not planning any changes to the current behavior.

[DibyaRanjan1]

OK. I thought you were planning to introduce some root file to fix this. Never mind. So the fix is to forcefully make the named value file change and include it in the commit.