Azure pipeline copy file task
up vote
0
down vote
favorite
We're trying to get some CI/CD up in here, so I'm trying to deploy a webservice via the Azure Dev Ops pipeline, but I'm running into an issue with the Web.configs. So far I've gone down the route of having a config per environment (DEV, QA, PROD) and figured I'd simply have the build process copy the relevant file on top of it with the copy file task. Everything was already zipped up at the release step so I did it at the build step.
I get the following output from the copy step:
2018-11-19T16:46:17.2133815Z found 1 files
2018-11-19T16:46:17.2141470Z Copying D:a1sBridgeConfigsQAWeb.config
to D:a1sWeb.config
2018-11-19T16:46:17.2226220Z ##[section]Finishing: Set Web.config to QA
I have it set to overwrite at the destination.
It looks like it's got the right files at the right directory, but when it gets to deployment, I still see the same (uncopied) Web.config at the root directory. Any ideas what might be happening here?
Alternatively, is there a good way to move the file around after deployment? It looks like the copy file task only has access to what's in the build artifact where everything is zipped up, and unzipping it sounds like the wrong idea to me.
Any help is appreciated, thanks!
Note: I was hoping to use this copy file thing instead of the various transform options because it seems simpler and I like having the separate configs in source control.
web-config azure-devops
add a comment |
up vote
0
down vote
favorite
We're trying to get some CI/CD up in here, so I'm trying to deploy a webservice via the Azure Dev Ops pipeline, but I'm running into an issue with the Web.configs. So far I've gone down the route of having a config per environment (DEV, QA, PROD) and figured I'd simply have the build process copy the relevant file on top of it with the copy file task. Everything was already zipped up at the release step so I did it at the build step.
I get the following output from the copy step:
2018-11-19T16:46:17.2133815Z found 1 files
2018-11-19T16:46:17.2141470Z Copying D:a1sBridgeConfigsQAWeb.config
to D:a1sWeb.config
2018-11-19T16:46:17.2226220Z ##[section]Finishing: Set Web.config to QA
I have it set to overwrite at the destination.
It looks like it's got the right files at the right directory, but when it gets to deployment, I still see the same (uncopied) Web.config at the root directory. Any ideas what might be happening here?
Alternatively, is there a good way to move the file around after deployment? It looks like the copy file task only has access to what's in the build artifact where everything is zipped up, and unzipping it sounds like the wrong idea to me.
Any help is appreciated, thanks!
Note: I was hoping to use this copy file thing instead of the various transform options because it seems simpler and I like having the separate configs in source control.
web-config azure-devops
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
We're trying to get some CI/CD up in here, so I'm trying to deploy a webservice via the Azure Dev Ops pipeline, but I'm running into an issue with the Web.configs. So far I've gone down the route of having a config per environment (DEV, QA, PROD) and figured I'd simply have the build process copy the relevant file on top of it with the copy file task. Everything was already zipped up at the release step so I did it at the build step.
I get the following output from the copy step:
2018-11-19T16:46:17.2133815Z found 1 files
2018-11-19T16:46:17.2141470Z Copying D:a1sBridgeConfigsQAWeb.config
to D:a1sWeb.config
2018-11-19T16:46:17.2226220Z ##[section]Finishing: Set Web.config to QA
I have it set to overwrite at the destination.
It looks like it's got the right files at the right directory, but when it gets to deployment, I still see the same (uncopied) Web.config at the root directory. Any ideas what might be happening here?
Alternatively, is there a good way to move the file around after deployment? It looks like the copy file task only has access to what's in the build artifact where everything is zipped up, and unzipping it sounds like the wrong idea to me.
Any help is appreciated, thanks!
Note: I was hoping to use this copy file thing instead of the various transform options because it seems simpler and I like having the separate configs in source control.
web-config azure-devops
We're trying to get some CI/CD up in here, so I'm trying to deploy a webservice via the Azure Dev Ops pipeline, but I'm running into an issue with the Web.configs. So far I've gone down the route of having a config per environment (DEV, QA, PROD) and figured I'd simply have the build process copy the relevant file on top of it with the copy file task. Everything was already zipped up at the release step so I did it at the build step.
I get the following output from the copy step:
2018-11-19T16:46:17.2133815Z found 1 files
2018-11-19T16:46:17.2141470Z Copying D:a1sBridgeConfigsQAWeb.config
to D:a1sWeb.config
2018-11-19T16:46:17.2226220Z ##[section]Finishing: Set Web.config to QA
I have it set to overwrite at the destination.
It looks like it's got the right files at the right directory, but when it gets to deployment, I still see the same (uncopied) Web.config at the root directory. Any ideas what might be happening here?
Alternatively, is there a good way to move the file around after deployment? It looks like the copy file task only has access to what's in the build artifact where everything is zipped up, and unzipping it sounds like the wrong idea to me.
Any help is appreciated, thanks!
Note: I was hoping to use this copy file thing instead of the various transform options because it seems simpler and I like having the separate configs in source control.
web-config azure-devops
web-config azure-devops
edited Nov 19 at 21:08
Daniel Mann
36.5k65884
36.5k65884
asked Nov 19 at 17:13
Josh Bowdish
31
31
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14
add a comment |
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14
add a comment |
1 Answer
1
active
oldest
votes
up vote
0
down vote
accepted
You've in part answered your own question. You'll need to do this copy work in a release pipeline rather than build so that the copy of the file can be contextual to the environment it has to function within.
For this reason you'll probably need to emit the web configs into the build artifact. Maybe copy them into a "configs" directory in $(build.artifactstagingdirectory). Then in your release pipeline it will download your artifact which will include your "configs" directory and all the environment configs and you can have a release pipeline task that based on the environment its in copies the right file from the "configs" directory in the artifact and copies it in-place to the root directory of the deployed web app.
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
accepted
You've in part answered your own question. You'll need to do this copy work in a release pipeline rather than build so that the copy of the file can be contextual to the environment it has to function within.
For this reason you'll probably need to emit the web configs into the build artifact. Maybe copy them into a "configs" directory in $(build.artifactstagingdirectory). Then in your release pipeline it will download your artifact which will include your "configs" directory and all the environment configs and you can have a release pipeline task that based on the environment its in copies the right file from the "configs" directory in the artifact and copies it in-place to the root directory of the deployed web app.
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
add a comment |
up vote
0
down vote
accepted
You've in part answered your own question. You'll need to do this copy work in a release pipeline rather than build so that the copy of the file can be contextual to the environment it has to function within.
For this reason you'll probably need to emit the web configs into the build artifact. Maybe copy them into a "configs" directory in $(build.artifactstagingdirectory). Then in your release pipeline it will download your artifact which will include your "configs" directory and all the environment configs and you can have a release pipeline task that based on the environment its in copies the right file from the "configs" directory in the artifact and copies it in-place to the root directory of the deployed web app.
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
add a comment |
up vote
0
down vote
accepted
up vote
0
down vote
accepted
You've in part answered your own question. You'll need to do this copy work in a release pipeline rather than build so that the copy of the file can be contextual to the environment it has to function within.
For this reason you'll probably need to emit the web configs into the build artifact. Maybe copy them into a "configs" directory in $(build.artifactstagingdirectory). Then in your release pipeline it will download your artifact which will include your "configs" directory and all the environment configs and you can have a release pipeline task that based on the environment its in copies the right file from the "configs" directory in the artifact and copies it in-place to the root directory of the deployed web app.
You've in part answered your own question. You'll need to do this copy work in a release pipeline rather than build so that the copy of the file can be contextual to the environment it has to function within.
For this reason you'll probably need to emit the web configs into the build artifact. Maybe copy them into a "configs" directory in $(build.artifactstagingdirectory). Then in your release pipeline it will download your artifact which will include your "configs" directory and all the environment configs and you can have a release pipeline task that based on the environment its in copies the right file from the "configs" directory in the artifact and copies it in-place to the root directory of the deployed web app.
answered Nov 20 at 18:52
Colin B
1666
1666
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
add a comment |
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
Thanks! This worked perfectly. One issue - I wasn't able to find a correct pre-determined variable for the root directory of my web app, I kept finding agent based stuff. Do you know if there is a variable for the root directory? Giving the absolute path on the machine is working though.
– Josh Bowdish
Nov 21 at 19:38
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
The agent doesn't have this intimate knowledge of where apps root directories are going to be deployed to as it is agnostic of the technology or platforms it can deploy to (i.e. deploying a apache java app is different to a .NET Web App on IIS). The only knowledge it really has is around the agent itself and it's directory placement then any System/Custom environment variables. Glad you got it working :-)
– Colin B
Nov 22 at 12:58
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53379618%2fazure-pipeline-copy-file-task%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Just realized this copy thing isn't going to work if it's at the build step if I want to take the pipeline to QA and then Production, so moving the file after deployment seems like the better option.
– Josh Bowdish
Nov 19 at 17:14