I have developed and released Smart Home Action,
Now I need to test it because I will modify that Action.
It will be a test with Actions on Google Project with released actions,
If I enable test,
Is it okay to understand that the following is displayed in the list of Smart Home Actions and can be used separately?
Does not it affect the released Action?
[the list of Smart Home Actions]
[test] xxx Action ←Test Action
xxx Action ←Released Action
If you know of this,please let me know.
You are correct that the "Test Action" is intended to reflect the current console configuration and any changes you make there will not affect production. However, Smart Home works a little differently than other Action types in ways that affect this behavior (we are working to improve this).
Once your Action is deployed to production, the project will no longer reflect console changes to the test agent until those changes are submitted and reviewed. The recommended way to work around this constraint is to create a second project in the Actions console that you can use to test/validate your change.
When you're ready to submit the updates to production, you can follow the steps outlined to updating your existing production project in Launching your smart home Action.
Related
I have enabled a couple of different code scanning tools in my GitHub Actions workflow that each upload their results to the GitHub Security tab (via upload-sarif).
One of these scans produces a lot of alerts that are not relevant for my project, as it scans the built container image and produces alerts for all of the packages and utilities included in the base (Linux) image regardless of whether they are used by my application. So I have reviewed all of the alerts on the GitHub Security tab and dismissed (as "Won't Fix") the alerts that are not relevant.
Subsequent executions of the GitHub Actions workflow on the default branch work fine - the code scanning tool still generates all of the alerts, but GitHub sees that the alerts have already been dismissed and doesn't add or re-open them on the Security tab.
However, I also want to run the scan on PRs targeting my default branch in order to catch any new alerts before they are merged. But here GitHub doesn't appear to be checking that the alerts have already been dismissed on the default branch, so the code scanning check fails on every PR. Worse, if I ignore the check and merge the PR anyway, the alerts are transferred over to the default branch and need to be manually dismissed again.
Is there a workaround for this, or should I be approaching this in a different way?
I have discovered that the code scanning tool in question (Trivy) does not include fingerprints in its SARIF output, which is what confuses GitHub. I've made a feature request for Trivy here: https://github.com/aquasecurity/trivy/issues/1840
As a workaround, I've discovered that keeping the container image name static for code scanning allows GitHub's fallback deduplication logic to correctly identify duplicate alerts.
Is it possible to create new branch directly from Issue which is posted on Github? We have project hosted on Github with many issues, it would be easy for us just to click one button in Issue web interface and create new branch for it to start developing.
This is not possible directly from the issue interface. I can try to provide you some workarounds and maybe start a debate why one would want this feature:
Creating branches directly on the web interface
After you've noticed that you need to start working on an issue you can just go to the repository main page (keyboard shortcut gc) and create a branch with the name you want:
Chrome extensions
If this is a must for you, you can create a chrome extension that augments the UI and creates a branch directly from the Issues WebUI using the GitHub API. There's a lot of open source extensions that augment the default WebUI.
Is it the most efficient way to start a new feature?
I think this changes from developer to developer, but having worked with GitHub for 7 years using Issues I've never felt the need for this feature because unless it's a one line change that doesn't require local testing or compilation, I still want to get down to my command line and IDE. If I have to do that, I still have to at least git fetch to get the branch I just created directly through the issue interface. If that's the case I've always preferred to just look at the issue and run git checkout -b branch-name, optionally with git push if my team needs to see the branch.
Then the issue name wouldn't normally translate to a branch name, at least I wouldn't want that. So that option to create a branch from an issue would probably need to spin out a prompt to allow me to name the branch what I wanted.
This is just my personal opinion and nothing else, hope it helps :)
GitHub finally added this feature request to their roadmap.
Summary
The branch is the first thing a developer creates when the start
working on a new issue. Creating that association makes it really easy
for someone to then follow the work happening and keep everything
connected as they take their idea to code.
Intended Outcome
We want to help developers get started on work faster and signal to
their team where to find the code changes related to an issue. It
should also be really easy to then follow development to the pull
request without the user needing to do additional work to link
everything together.
How will it work?
From the issue page, a user can quickly create a branch with an
auto-generated or custom name that becomes associated with the issue.
They can then fetch the branch and switch to it in their development
environment and further development changes (such as commits and pull
requests) are automatically associated with the issue.
https://github.com/isaacs/github/issues/1125
Nope. You can subscribe this issue.
You could accomplish this by creating a small script.
I'd start by leveraging the Issues Event webhook. This will fire a JSON payload every time an issue is opened. When the webhook fires, your script can then create a new branch using the Create a Reference API endpoint. Note: URL must be formatted as heads/branch, not just branch.
There is an app that automatically creates branches for issues. You can install it here for free: https://github.com/marketplace/actions/create-issue-branch
If you want to create the branches manually instead of automatically:
It does not enable you (directly) to click on create branch from the issue. Instead you would have to write a comment in the issue consisting of: /cib. If you do that, it automatically creates the branch from the issue.
Please note I have no affiliation with the app.
Recently I saw that Github finally added this feature to its Issues Panel.
All you have to do is navigate to an Issue on Github and scroll down to the following section:
I'm a developer and want to integrate with ServiceNow. Im new to ServiceNow and I have probably a very simple question. I created a workflow in the worflow canvas and validated and published it. When I click the play button nothing happens. Here is the document I followed.
How do I know that the workflow is working? I can't see any animation too.
My current worflow is: Begin->workflow fires when incident state is New or Active. ->End . I created an incident and changed the states to these 2 values, but no luck.
Let me know how to make sure that workflow is working.
Thanks in advance!
Whenever a workflow executes, this is represented as a "Workflow Context." You can look at the status of current or past contexts by navigating to "Workflow" > "All Contexts" in the nav menu.
That menu link will take you to a list of Workflow contexts (table name: wf_context). You can locate your test executions by 2 columns, "Workflow version" and "Related record." The Related record column will have the Incident number that triggered the workflow, and the Workflow version column will have the name of the test workflow you are working on.
Once you open up that record, there's a lot of useful information in there for examining the details of the workflow execution. Among that info is a workflow log, activity history and transition history. As you continue developing your workflow these will provide useful debugging data points if you encounter obstacles.
Workflow is a fairly deep concept, so I recommend glancing at this article as well, once your feet or sufficiently wet.
Workflow Concepts
Refresh NetSuite sandbox from production (code only)
I realize that we can refresh out sandbox from production but we don't want to refresh the entire sandbox, instead we want to refresh NetSuite SuiteScript, NetSuite Forms & UI Objects.
NetSuite's proprietary infrastructure/code and challenge it brings
I resisted asking this question for several weeks thinking it was too basic but it doesn't appear that way. After working with NetSuite for a while it has become clear that the line between source code and data has become blurry and it's my opinion this is exactly what makes refreshing code challenging.
I've also learned that storing NetSuite code in version control software is next to impossible (for all code) and this leads me to believe that my desire to refresh code only might be impossible as well. I have to wonder how IT shops that are encumbered by SOX compliance issues are able to satisfy auditors when it comes to controlling and modifying the business logic.
The real question and reason for refreshing the sandbox code
My motivation for refreshing sandbox code is the fact that we are encountering unexpected behavior in our sandbox accounts with certain forms (invoice & estimate) where custom tax fields (Ava-Tax) mysteriously moved from the items tab to a tab that contains transaction body fields! The form appears to not have been updated by anyone in over a year and there were no packages installed in the sandbox that might have broken the form.
If I cannot refresh source code is there a way to determine how a NetSuite form became corrupted knowing that the NetSuite Form is stored in a proprietary way and with no apparent source code available? I understand most of the NetSuite code is JavaScript that runs on both the server and client and there are parts that are unavailable to anyone outside of NetSuite.
Any solutions or suggestions are welcome and appreciated.
It is not at all impossible to store NetSuite code in Source Control. We use git to track all of our NetSuite source, and we follow a process similar to gitflow. Our master branch is always kept in sync with Production. Anytime we push code to Production, that gets merged from its feature/fix branch up to master and tagged as a release. If we want to roll back, we just revert master back a commit and upload the whole project to the File Cabinet. Then, if we want to refresh a Sandbox to match Production, we simply checkout master and upload all of that to the Sandbox.
Sandboxes themselves are much more difficult to keep in sync with a single branch in source because we are constantly developing there on separate feature branches.
If you do not already have such a system in place, all you really need to do is download the zip of your SuiteScripts folder from the Production File Cabinet and upload that to your Sandbox.
This isn't source control, but you can use SuiteBundler to copy items between accounts. SuiteBundler allows you to choose from a lot of things like forms, scripts and custom records. Later you can uninstall the bundle or dissolve it into the account.
It's not so easy to explain in few words, here but: You can use a deployment account to get things work properly. So you continuosly work on dev accounts and use multiple bundle / bundle version for follow branches/Versions of customizations. You update bundle from dev to deploy account only when a version is stable and production envs always install / update bundle version from deploy (not from dev). Since bundles are versionable and infinite, you can use git + dev + deploy account for manage Cvs. For get a versionable version of a form just add &xml=t in url in any form. But this is read only
I would like my builds to behave differently (a handling script needs to know) if a person requested the build through the UI "build now" button, or if it was triggered by SCM. I don't want to have to provide a checkbox in the UI that the users have to alter - I've already gotten blowback from them about such things. Trouble is, any parameter I set has the same default regardless of how the build is triggered.
You should not really have 1 job with different behaviour. If you need different behaviour set up a job per behaviour. Best bet in your case is to have 2 separate jobs, one for the SCM triggered builds, and one for the manually triggered builds.
There's a plugin to allow you to filter jobs into separate pages (can't remember the name at the moment). You could set all SCM builds on 1 page and manual builds on another, then set the manual build page as the default one on login. Users will only see the jobs you want triggered manually by default, but can still access the SCM triggered builds by selecting the other page.
Could you somehow check the SCM polling log during the pre-build (with a script), and then go from there?