I have developed Azure DevOps extension and published it to marketplace. Recently I have came across mandatory UI changes. While performing dev testing, I have noticed that once I install new extension (with UI changes) it still showing old UI components.
For example, let’s say I have string input named “Name” and I have replaced it with “Full Name”. I still see my old input which is “Name”.
Old :
{
"name": "name",
"type": "string",
"label": "Name",
"required": true
}
New:
{
"name": "fullName",
"type": "string",
"label": "Full Name",
"required": true
}
I removed temp files under below locations, but issue persists.
C:\Users\<< User Name >>\AppData\Local\Microsoft\Team Foundation\
<< Agent Folder >> \ _Work\
Windows Temp folder
I have changed the task id (GUID) and it seems resolving this issue. But this is not viable solution as I cannot issue new task id for already published extension.
Due to this reason I believe best option to resolve this issue is deleting cached data. Please let me know, Where does the Azure DevOps / TFS cache it’s extension data?
Thanks in Advance!
Try to clean the browser cache, and check whether you have increase the version number in the task.json.
Also, try to Delete task -- Save definition -- add task again, which should help.
For me solution with updating task version and removing browser cache didn't work. I found the DistributedTask folder in one of subfolders in the root cache folder. In my case it was cache_root_folder/<some_uuid>/Proxy/<another_uuid>/DistrebutedTask/. I dont know what these UUIDs mean and found this path just accidentally. Removing all from this folder helped.
Related
I'm trying to translate my company's project from legacy build tool to bazel. Now I'm facing this problem and searched a lot, but unfortunately, I haven't had a clue so far.
Here's the thing:
For compliance with open source audit, we must provide a list of open-source software which are built into our binary. As external dependencies are introduced by repository rules, my intuitive thought is to query these rules and get the URLs. However, subcommand query/cquery hasn't provided such functionality yet AFAIK, it can print rule/target/buildfiles but no repository rules nor their attributes.
Is there a way that I can gather such information from repository rules in WORKSPACE? It's not viable to do it manually as there are thousands of projects in my company and the dependencies also change frequently.
For example, a workspace rule:
http_archive(
name = "testrunner",
urls = ["https://github.com/testrunner/v2.zip"],
sha256 = "..."
)
This dependency is used by a rule named "my_target", so what i expected is that the dependency could be queried like this:
> bazel queryExtDep my_target
External Dependency of my_target: name->testrunner, urls = "https://github.com/testrunner/v2.zip"
--experimental_repository_resolved_file will give you all that information in a single Starlark file, which you can easily process with Starlark or Python etc to extract the information you're looking for.
The resolved file looks something like this:
resolved = [
...,
{
"original_rule_class": "#bazel_tools//tools/build_defs/repo:git.bzl%git_repository",
"original_attributes": {
"name": "com_google_protobuf",
"remote": "https://github.com/google/protobuf",
"branch": "master"
},
"repositories": [
{
"rule_class": "#bazel_tools//tools/build_defs/repo:git.bzl%git_repository",
"attributes": {
"remote": "https://github.com/google/protobuf",
"commit": "78ba021b846e060d5b8f3424259d30a1f3ae4eef",
"shallow_since": "2018-02-07",
"init_submodules": False,
"verbose": False,
"strip_prefix": "",
"patches": [],
"patch_tool": "patch",
"patch_args": [
"-p0"
],
"patch_cmds": [],
"name": "com_google_protobuf"
}
}
]
}
]
This includes the original attributes, which is where that URL you're looking for is. It also includes any additional information returned by the repository rule (ie for git_repository, the actual commit a given ref refers to).
I got that example from blog post introducing that flag, which also has some more background.
I have the issue I would like to automate via a script so tat .jnlp will be added as an allowable type of file , is there a command like or powershell or regedit that will add it?
The latest file types policies are published in the Chromium source code. You could clearly see that the danger_level of .jnlp type files is DANGEROUS. Therefor Edge will warn users that this file may harm their computers. Let users continue or discard the file.
If you ensure that the content(download file) on the site is safe, you can use this policy to specify the file types that are allowed to be downloaded continuously from a specific site: ExemptDomainFileTypePairsFromFileTypeDownloadWarnings.
Example:
[ { "file_extension": "jnlp", "domains": ["contoso.com"] }, { "file_extension": "exe", "domains": ["contoso.com"] }, { "file_extension": "swf", "domains": ["*"] } ]
If you want to achieve the same function through the registry, you can set it under this path: SOFTWARE\Policies\Microsoft\Edge\ExemptDomainFileTypePairsFromFileTypeDownloadWarnings
I'm trying to package my electron app, using electron-forge. In order to make the app available on macs, I need to codesign the app, which requires passing info such as appleId and app-specific-password in the package.json file.
How can I pass this information securely? (ie, not available to people who download the app)
If environmental variables are the way to go, I'm hoping to understand where I set the environmental variables (in a separate file? In the start command?) and how I access them in the package.json itself.
I'd appreciate any help to sort this out.
Details of what I've considered:
-The electron forge codesign documentation does not mention how to actually provide osx required details in a secure way. It does mention that it uses electron-notarize (among others) under the hood, and electron-notarize's documentation says: "Never hard code your password into your packaging scripts, use an environment variable at a minimum", but doesn't provide detail on how to do that.
-This stack overflow answer provides helpful info in terms of setting up a separate forge.config.js file, and then says you should "load your environment variables using process.env.YOUR_VARIABLE_NAME". It doesn't provide more detail--loading the environmental variables for a packaged app is what I'm trying to figure out here.
--This stack overflow answer mentions setting them manually, but doesn't mention how. It also mentions using the dotenv package--but I'd be surprised there's a separate package required for this task that is fundamental to any mac electron app.
I store them in an .env file in my project directory as follows:
APPLEID=your_id
APPLEIDPASS=your_password
In package.json I have a section:
"build": {
"productName": "PRODUCT",
"appId": "your app id",
"copyright": "Copyright",
"directories": {
"output": "build"
},
"afterSign": "scripts/notarize.js",
The afterSign points to a script scripts/notarize.js that will pull out the APPLEID and APPLEIDPASS using dotenv:
require('dotenv').config()
const { notarize } = require('electron-notarize')
exports.default = async function notarizing(context) {
const { electronPlatformName, appOutDir } = context
if (electronPlatformName !== 'darwin') {
return
}
const appName = context.packager.appInfo.productFilename;
return await notarize({
appBundleId: 'your app id',
appPath: `${appOutDir}/${appName}.app`,
appleId: process.env.APPLEID,
appleIdPassword: process.env.APPLEIDPASS
})
}
It's those 2 last lines with appleId and appleIdPassword that pull out the environment variables.
Never commit the .env file to, for example, github. To make sure: add .env to your .gitignore file. Also: the script/notarize.js app is not part of your app itself, this runs while you build your app.
I've been able to hear back from one of the maintainers of electron forge, who said the way to do it is:
Load the environmental variables in the build script itself. For example: $ VAR1=something VAR2=somethingelse npm run make.
Then, reference those variables as appropriate in the forge.config.js file that package.json refers to. Example reference syntax: process.env.VAR1
Developed an Electron app using Vuejs and everything works fine in development, but when packaged I keep getting this pop-up after start up (NOTE: This is a sample image - mine doesn't say 'windowsdefender' but is otherwise the same).
Using electron-builder to create the application with the following build json, and it is installed on the PC:
{
"productName": "My App",
"appId": "com.mycompany.myapp",
"win": {
"icon": "build/icon.png",
"target": [
"nsis"
]
}
}
Though the app does open, there is no initial screen. However, I can open the dev tools but there are no errors displayed.
Any ideas on what is causing this or how to resolve?
After many tries, I finally figured it out (or at least I think I know what caused the issue).
The primary issue was that in using vue router (from an app ported from the web), it is important that you use 'hash' mode and not 'history. Add this to your router file:
const router = new VueRouter({
mode: process.env.IS_ELECTRON ? "hash" : "history",
routes
});
See this link for more details (common issues): Vue CLI plugin common issues
Second, I think there is a rights issue (i.e. having elevated rights to install) so I added this line along with the guid to my electron-builder.json file. The result was a build file like this:
{
"productName": "My App",
"appId": "com.abcco.my-app",
"win": {
"icon": "build/icon.png",
"target": "nsis",
"requestedExecutionLevel": "requireAdministrator"
},
"nsis": {
"guid": "6ee647a9-d5c6-46a9-a480-aa7d6d3d1c10",
"oneClick": false,
"allowToChangeInstallationDirectory": true
}
}
As I am developing only for Windows I was able to use material from this page (React but not that different with respect to Electron packaging):
Electron Build file help
The last thing I did was to remove all 'dist' files and uninstall the app entirely (previous versions). I think this cleared up a lot of the 'baggage' left over from testing.
Hopefully this helps others who may experience the same issue.
We have developed VSTS/TFS extension which consists summary page with details generated from our extension task, at the end of build.
we have added contribution similar to below in manifest file to add this summary section
{
"id": "build-status-section",
"type": "ms.vss-build-web.build-results-section",
"description": "A section contributing to our own new tab and also to existing build 'summary' tab",
"targets": [
".build-info-tab",
"ms.vss-build-web.build-results-summary-tab"
],
"properties": {
"name": "Custom Section",
"uri": "statusSection.html",
"order": 20,
"height": 500
}
}
However currently we are facing issue as even when user not add our extension task in to his build our summary page will appear in summary tab (if our extension is installed and enabled).
Is there any way to avoid displaying summary section when our task is not added to their build. Please be kind enough to help on this.
No, you can't hide the summary section.
This is because build-results-summary-tab is used for all builds. So when you install the extension, even you are not add the task you developed, the summary results will be showed for any of build results.
More details, you can refer Referencing contributions and types and the example as Targetable hub groups shows.
The work around is that you can separate build-results-summary-tab extension with the build task extension (use two extensions instead). For the accounts need to view the summary result, they can install the two extensions. Else, the accounts just need to install the extension for the build task.