I have an issue with uploading a renewed Apple push certificate for a Azure Notification Hub. It states that the path is to long.
Error updating notification hub:
{"error":{"message":"The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.","code":"InternalServerError"}}
I do not understand how such a error is relevant to an Azure service. All the solutions to this problem pertains to changing the folder reference to a shorter name in a config file (web projects). The web project itself is on another instance.
Yes, there was an issue with this. The Notification Hubs team has now fixed it.
Related
Every time I publish my project my folder permissons get removed. My project requires IIS APPPOOL\appPoolName and IUSR to have specific access right to specific folders.
Whats the best way to apply the folder permissons after the artifact has been published?
Not sure if totally get your point. You can use location elements in the web.config file, there is a lot of information on the web about that - this gives you a start: HOW TO: Control Authorization Permissions in an ASP.NET Application
Besides, for folder NTFS permissions here rather than web security permissions. You could also add a custom target to Visual Studio's web publishing pipeline. For detail ways please take a look at what Sayed Ibrahim Hashimi does here.
I am working on an Android project. I have a few files under version control that git-crypt encrypt them for me. The content of some of them is important to be decrypted before running the build process.
I have no problem at all with building the project on my laptop. The problem is on the the CI side. When I push the code to the Origin, the pipeline (I am using Azure) triggers a pipeline and after a few seconds, the build fails. That's because the build system is looking for the information I have in keys.properties file and it's encrypted.
Based on my understanding, git-crypt uses public/private keys in order to encrypt/decrypt files. The public key is already under the version control, root/.git-crypt/keys/default/0/7F64F6C566153F29E4D9D44070C2A1QW029CE338.gpg. Therefore, I think I need to move the private key somewhere. Am I right? If I am right then my question is where to put it? Is it still under the root of the computer (macOS Image/VM on CI) or I can put it under the root of the project?
Note: Azure lets me upload secure files under its Libraries and then I am able to reference it from the azure-piplines.yaml file.
where to put it?
Based on my understanding on git-crypt and azure devops, compare with storing the private key in root of PC, I'd suggest you put it under the root of project.
Because if you store it at root of PC, it would has no trouble while you run the pipeline with Private agent. BUT, what the issue is if someone using Hosted agent but the private key is in local. As you know, Hosted agent is the one which located at cloud, and it is loaded very dynamically. So, it's hard to get the private key from local computer.
In one word, keeping it in the repository remove the hassle of storing it somewhere else and using it between developers.
However, above is just the suggest choice between store at root of PC and store at root of project.
Although, it would much convenient if put the private key into the root of project.
But on personal suggestion and info security, I strongly stand by the method that you mentioned at last: Store the private key in Library, and reference it during the build/release. Azure DevOps library store the secrets in a safe way and use them as and when needed without making it visible to anyone.
I am building a very small Node/Express API app in Azure using Twilio to route communication for a small group. I initially built out a data structure for users in CosmosDB but found out it's minimum $24 per month, which is way over budget for something that will likely hold 20 or so records. Because of this, is seems much more reasonable to just build this into a json file that sits in a ./json subfolder. However, it has occurred to me that whenever I deploy, I would be overwriting this file with the default file I have locally. I have been working via the Azure App Service tool in Visual Studio Code and can't figure out a way to make it ignore the file.
I can go into Kudu and copy the file down each time before I deploy, but I will eventually forget and this sounds like a very brittle process.
I added a json/ line to .gitignore, but that has no effect on the deployment (as expected).
I also added "appService.zipIgnorePattern": ["json{,/**}"] to the settings.json file, but instead of just ignoring that folder on the server, it erases it on deploy (the zip ignores it and then it wipes/replaces the whole wwwsite folder). Looking for the file gives me {"Message":"'D:\\home\\site\\wwwroot\\json\\users.json' not found."}
I was hoping there is a setting that would deploy, replacing all folders in the package, and ignoring all content in the ./json folder. Does this exist?
Alternative solution, 2021:
Instead of excluding folders, select the folder that you do want to deploy. Data in other folders will not be affected.
Deploy from: edit .vscode/settings.json in your local project and add "appService.deploySubpath": "./folderToDeploy"
Deploy to: In the Azure Portal go to your app service. Under Configuration / Application Settings add a new Application Setting with name SCM_TARGET_PATH and value ./folderToDeployTo
Using VS Code right+click deploy will deploy the contents of the folder. I was able to work around this by adding Azure as a remote branch and using .gitignore. I placed my json file inside a random folder (content/json) then placed /content/json in my .gitignore file.
I am trying to push app to cloud foundry from Jenkins. And it complains of this :
org.cloudfoundry.client.v2.ClientV2Exception: CF-AppResourcesFileModeInvalid(160003): The resource file mode is invalid: File mode '444' with path '.git/objects/pack/pack-af4cdbe6faac9d245253dafc1ecae06dc3fa5816.pack' is invalid. Minimum file mode is '0600'
at org.cloudfoundry.util.JobUtils.getError(JobUtils.java:81)
at reactor.core.publisher.MonoThenMap$ThenMapMain.onNext(MonoThenMap.java:120)
at reactor.core.publisher.FluxFilter$FilterSubscriber.onNext(FluxFilter.java:96)
I have tried:
1.Doing chmod 666 ( and even 777) before the build step.
2.Adding these in my .cfignore:
scripts
.git/
.git/objects/pack/*
plugins/**/*
/.bundle
tmp/
.pack
Wiping off workspace in jenkins and app on cf before another try.
Nothing works.
One interesting thing is after a fresh commit to .cfignore (editing a line and pushing to git) , the first build in jenkins works. Subsequent build fails.
Any help?
Thanks!
The root issue is that the Cloud Foundry Java Client pushes the entire content of the configured path to the server. The Cloud Foundry CLI automatically filters out source control directories (and possibly all hidden directories) this filtering out the most common places to see < 0600, but that’s not actually documented anywhere so we don’t match that behavior. I’ve chatted with the lead of the CLI and they’ll document that behavior at which point we’ll implement what they spec.
The .cfignore file does’t work in the client yet either, but once that is properly spec’d by the CLI team, we’d work that issue as well.
I wan to start a Google Transit project (a city transport feed for google maps) and for the purpose of collaboration I want to use GitHub. Now one great thing is that GitHub is offering a ZIP file download that contains all your repository, and Google wants a ZIP with a required data, but that file should have name: google_transit.zip.
So my question is:
Can I somehow give Google a link that will give it a file called google_transit.zip, that will contain all the stuff that's in the master branch? Maybe this can be done with standard "download zip" option or with some hooks or something else…
GitHub will allow you to automatically download a Zip archive of the latest version of a branch using the following url:
https://github.com/:user/:repository/zipball/:branch [GET]
The archive will be given a special name following the git describe command output.
However, there's one way to achieve what you're after by leveraging the GitHub Repo Downloads API.
Every time your master branch is ready to be published, you'd execute the following steps:
If the download resource google_transit.zip already exists, remove it
Create a new download resource and name it google_transit.zip
Upload the latest zip archive using the provided information of the previous request
There's even a Ruby library (ruby-net-github-upload) that may help you automating this task.